This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
* Yann E. MORIN <yann.morin.1998@anciens.enib.fr> wrote: > When I build a toolchain, what I *do* want is for the toolchain to be > based on _upstream_, and know what changes _I_ am doing to these. Yes, that's what the UPSTREAM* refs in oss-qm are for ;-p > Patches are much more manageable than a VCS (whatever be it), > because I can very easily list all individual changes, without convoluted > command lines, without access to the repos, all on my HDD. I've been working with patches (even oss-qm) for quite a long time, but by switching to git I found it *much* easier and faster in daily work (not just maintaining the end-product, but the whole way towards it). Most of all: I'd never like to miss the rebase operation again. It's the center of my daily workflows. (and I'd never like to miss tig!) > And if I am not pleased with the patchset, I can drop it, or even switch > to my very own local one. That's also easily possible w/ git: interactive rebase and kick out the unwanted patches (I'm doing that nearly every day) ;-p Yes: it requires some more keystrokes than simply deleting a patch file from a directory. But: then you've got now guarantee that the remaining will apply again. You'll have to get a fresh upstream tree and apply them all manually (unless you don't want to run the whole ct-ng machinery for half an hour just to find out that some patches failed). And if some patches failed, you'll have to manually replay the changes and diff them out again. In the end, this goes down to an rebase operation again - regardless if you're doing it manually or with the help of an proper vcs. > Using a central repository where random people, from random projects, > can push random stuff which I may not even be remotely interested in, > is simply not an option. That wasn't my proposal. I proposed using git repos w/ an standardized naming scheme, and then automatically push everything into an central one (or let my bots fetch it automatically). > Plus, that smells like, hmmm... <whisper>fork</whisper>. Indeed. You're already doing the fork (virtually and distro does that). More precisely: an downstream fork (meaning: directly based on certain upstream releases, implying frequent rebase operations) - regardless of the used tools and whether you call it so. > You could argue to that that I do not even remotely know even the most > important committers of gcc/glibc/whatever. No, I don't. But those > projects are doing _releases_. The biggest of those projects (Linux, > gcc, glibc, binutils) even have at least a basic Q&A plan before a > release is cut. And for the last major project (uClibc), those are people > I _trust_. That's not the issue. The only possible point of mistrust is the repo you're pulling your base from. If the upstream doesnt supply an official one, you'll have to trust the maintainer of your mirror (assuming you're not doing that on your). > [*] glibc is the _one_ exception to the rule, as the only official > distribution is via their git tree. Even so, there are non-approved > tarballs that smell like official, being served from the historically > official ftp. And old versions are available as official tarballs. > YEM. Last thing I heared, gcc has also a public git repo (which yet is an mirror to cvs, but maintained by gcc people). cu -- ---------------------------------------------------------------------- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weigelt@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ---------------------------------------------------------------------- -- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |