Re: git? branch-2-2?

[Gary V. Vaughan]

Howdy Bob,

On 4 Mar 2008, at 17:29, Bob Friesenhahn wrote:
> On Tue, 4 Mar 2008, Ralf Wildenhues wrote:
> > > As far as cramping Gary's style goes, Gary (only used as an example
> > > here) is prone to making large changes, and these changes may soon
> > > render 'master' useless as a good source of patches for stable  
> > > branches.
> >
> > Ah, no, this problem is easily avoided.  git cherry-pick allows you  
> > to
> > pick individual patches from one branch into another.

I feel cramped by CVS!  That's why I invested considerable effort into  
maintaining an Arch mirror for my own work on Libtool.  I feel that my  
style is to hardly work on the tree at all for months on end, and then  
when a flash of inspiration to improve some part of Libtool strikes:  
to work frenetically on deep changes for a while, and then back off  
while the dust settles :-)

With a better distributed system, I'd happily confine my source quake  
to a public topic branch rather than juggling a private quilt patch  
stack.  I'd like to think that might encourage people to jump in and  
help out with the deep changes, since they won't have to wait for me  
to pull back the curtain at the very end of my process to see what  
I've been doing.  (Arch helped a lot in that regard, but was too much  
work to maintain outside of the blessed repository.)

Also, if maintaining patches outside of master and stable (but still  
in public) is easy enough for me, I might feel a lot more inclined to  
help out with the more mundane aspects of maintaining Libtool rather  
than working away behind the scenes towards my occasional source-quakes.

> My point is that as the master version advances in time, the  
> baseline for submitted patches will become more and more different.  
> Eventually a patch from the master version can not reasonably be  
> applied against a stable branch.

That's no different to the effort involved in porting fixes on  
branch-1-5 forward to HEAD in CVS.

Ideally, we should be aiming to release frequently enough that there  
isn't 4 years of difference between master and stable, so this can be  
a much smaller problem for future releases.

Incidentally, I suppose we should set about defining a sensible set of  
goals for Libtool 2.4 reasonably soon...  I'll raise that again when  
2.2.2 is done.

> One reason why I have not contributed all that much to libtool  
> sources is that the level of effort to produce an emailable patch  
> for peer approval on this list substantially "raises the bar" for  
> contribution. While the patch is waiting to be approved, the local  
> changes sit uncommitted in a working directory, hindering further  
> work on the same files.  Each developer needed to develop his own  
> system for working around this limitation.  I never did.  It seems  
> that git has much more to offer to meet these needs than CVS does.


I had a half baked solution in cvs-utils (from which our commit script  
is taken), and then moved to quilt which handles the ugly parts of  
tracking a moving target underneath our patches.  Git makes all of  
this at least as easy, but without all the extra glue.

I'm looking forward to your patches now :-D

Cheers,
        Gary
--
  ())_.              Email me: address@hidden
  ( '/           Read my blog: http://blog.azazil.net
  / )=         ...and my book: http://sources.redhat.com/autobook
`(_~)_

PGP.sig
Description: This is a digitally signed message part