libtool-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: git? branch-2-2?


From: Ralf Wildenhues
Subject: Re: git? branch-2-2?
Date: Tue, 4 Mar 2008 23:11:14 +0100
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

* Bob Friesenhahn wrote on Tue, Mar 04, 2008 at 11:04:39PM CET:
> On Tue, 4 Mar 2008, Ralf Wildenhues wrote:
>
>> And no, emailing of patches is not more often necessary than now, i.e.,
>> mostly for posting "OK to apply" mails.  That can even be done more
>> easily, since there is a "git format-patch" command which will create
>> formatted message(s) for this purpose.
>
> So if a patch is pulled from 'master', then I assume that the derived  
> patch which will be applied to the branch will always be posted to this 
> list?

Erm, that could be done, but really those are two separate issues.

> 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.

Also, I didn't mean to say "every change that happens on branch-1-5 must
also happen on newer branches".  I do think this is a very good policy
and as such should be the rule, but obviously it cannot be carried out
if the branches are too different.  Also, when merging or
cherry-picking, things like ChangeLog entries typically need some help
(there is a ChangeLog merge driver written by Bruno in gnulib).

> A goal of a new versioning system should be to uninhibit creative people 
> while somehow keeping everything manageable in order to make periodic 
> releases.

I'm pretty sure git will be a step forward toward this goal.

> Perhaps libtool will become much more stable into the future? Libtool has 
> a long history of substantially morphing as new major releases are 
> developed.  Maybe libtool is to the point where only portability and 
> maintenance fixes will be required, or perhaps we will enter more rounds 
> of substantial development.

Well, I for one certainly welcome improvements which turn out not to be
intrusive.  When good advantage may be taken from more intrusive ones,
we may just have to look.  I think one good lesson learned is that we
should require much more test coverage for all kinds of changes.

Cheers, and thanks for your comments!
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]