[Top][All Lists]
[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
Re: git? branch-2-2?, Gary V. Vaughan, 2008/03/04
Re: git? branch-2-2?, Eric Blake, 2008/03/04