On Sun, Apr 17, 2011 at 10:01:55PM +0200, Dominik Vogt wrote:
> On Sun, Apr 17, 2011 at 06:24:37PM +0100, Thomas Adam wrote:
> > On Sun, Apr 17, 2011 at 07:09:15PM +0200, Dominik Vogt wrote:
> > > * The topic branches should usually belong to only one developer.
> > > The owner of a topic branch is responsible for keeping it in
> > > sync with the devel or release branch. The final result of a
> > > topic branch is a well structured patch set that applies to the
> > > release branch out of the box (with git-am or git-cherry-pick).
> >
> > One other option (which helps with the above in terms of keeping things up
> > to do date) is to consider rebasing local topic branches on top of the
> > development branch, periodically
>
> THis is actually what I wanted to suggest.
Good, because it's key to your last suggestion (I'll get to that. :))
> > -- but this breaks down if it's a published
> > branch with different people tracking it (potentially) -- perhaps
> > communication alone would help here (it does in git.git's use of "next" for
> > instance, and that's considerably larger than this project. :P)
>
> Some "problems" can only solved by communicating. If somebody
> publishes temporary work for inspection and testing by others,
> they can not expect that the branch is released as is. If they
> really need a certain point in the commit history, you can always
> set a tag to preserve it. This is good practice anyway before
> doing a rebase (in case something goes wrong or you find out that
> you still need the old stuff).
Yup.
> > > > merge to master for release" branch. It might look like this:
> > > >
> > > > o--o--o--o--o--o--o--o--o--o--o--o--o--o--o (master)
> > > > \ \
> > > > \ o--o--o--o--o--o--o
> > > > (next)
> > > > o--o--o--o--o-------------------------/ (ta/titleformat
> > > > merged)
> > >
> > > This is a situation to be avoided, if possible. Merge operations
> > > are dangerous and hard to track. It is worthwhile to stick to the
> >
> > I'm surprised to hear you say this, given that git's main feature *is*
> > merge-tracking, and long-lived topic branches could always be rebased first
> > of all -- if you also use the "--no-ff" option to "git merge" you'll also
> > have a merge commit recorded.
>
> My points are:
>
> * Merging branches that have been created a long time ago can,
> no, *will* generate hard to resolve merge conflicts. That is
> because neither the author of the branch nor the author of the
> conflicting change are usually able to do the merge alone
> because they do not know what the other has done why. The
> situation can become even worse because the conflicting changes
> may be old and nobody remembers their exact purpose exactly.
> I've seen this situation *so* often in every revision control
> system I have used.
Agreed. But see all the way back to the first paragraph; rebasing helps
here, but the onous is on the author of the branch and/or the poor sod of a
maintainer trying it integrate it. I've similar sob stories myself in both
cases from $DAY_JOB too.
> => Long term branches, yes, but the author should try hard to
> rebase them to the top of the release/devel branch regularly.
And this is what I think we're both fundamentally saying. Yes. I agree,
because then...
> Instead we rebase the topic branch to the HEAD of the master
> first, fixing any conflicts in the individual commits:
>
> A---B---C---D---E master
> \
> b'--c'--d' topic
>
> And now we merge the topic into the master:
>
> A---B---C---D---E-----------M master
> \ /
> b'--c'--d' topic
>
> This scheme should avoid any overlapping merges.
... and gives a linear history (no criss-cross merges), and is exactly what
I said somewhere in my reply.
So yes, I think we've got it now. :)
I skipped some points in your reply -- but I did read them.
This needs writing up, I suppose I'll do that?
-- Thomas Adam
--
"Deep in my heart I wish I was wrong. But deep in my heart I know I am
not." -- Morrissey ("Girl Least Likely To" -- off of Viva Hate.)
