Re: git? branch-2-2?

[Ralf Wildenhues]

Hi Bob,

* Bob Friesenhahn wrote on Tue, Mar 04, 2008 at 10:23:57PM CET:
>
> I think that this topic should be discussed on address@hidden before  
> the final decision because not only libtool maintainers retrieve sources 
> and submit patches based on the version control system.

Sure, why not.

> On Tue, 4 Mar 2008, Ralf Wildenhues wrote:
>> 3) If yes and yes, do you agree with the proposed git policy:
>> master should usually not contain merges except for merges from public
>> topic branches, should we have such in the future.  Generally, master
>> should be the first to receive a patch, and stable branches should
>> cherry-pick from master.  In your local trees, you should rebase private
>> topic branches against the upstream tree before inclusion.
>
> I would like to see more open discussion of this since git is a sort of 
> toolkit which can be used in radically different ways.  Git is capable of 
> supporting both cooperation and total anarchy.  Besides official 
> maintainers, we have others to worry about.

Yep, true.  What I was thinking of was to use now-existing savannah
infrastructure, namely a public git repo.  In a first approach, that
repository could just contain the active release branches (branch-1-5,
branch-2-2, master).  These branches should always strictly go forward,
i.e., existing history may not be undone.

> A concern about basing changes to stable branches on the master version 
> (new term for head?)

Yes, git uses the word master; since the term HEAD also has meaning in
git, it's better to not confuse this.

> is that it seems to keep master from flourishing 
> like it could.  Perhaps it might cramp Gary's style.  If this is wrong, 
> then please explain further for the git-impaired.

I have no idea whether Gary's style may be impacted, but I would doubt
it.  All I meant to say with cherry-picking from master to stable was:
patches should not flow from older branches to newer branches.  And we
should avoid merging between the branches: merging brings in not only
the most recent change, but all changes missing from the merge target's
history.

Since git is distributed, I think developers will have much more
freedom in organizing their work as appropriate.  Gary can have several
branches of his own in his repo.  In fact, I do have several Autoconf
branches in my private repo, each representing work on a different
issue.  I frequently rebase them against the public master on savannah.

> If patches are retrieved from local trees, I assume that this requires  
> that the local trees have a git server running?

No.  You can push from a private repo to the public one on savannah, if
you have write access to it.

> Otherwise patches would 
> need to be emailed or the local tree needs to belong to a maintainer with 
> ability to submit to the golden repository.  The apparent flexibility of 
> git is confusing to me.

Yeah, I know.  It's very confusing at first, and typically needs someone
to walk one through the first few steps.  Gets better though.

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.

Cheers,
Ralf