This is the mail archive of the 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]

Re: ct-ng -> git repos instead of single patches

* Yann E. MORIN <> 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).

 Enrico Weigelt, metux IT service --

 phone:  +49 36207 519931  email:
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme

For unsubscribe information see

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]