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.
> -- 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).
> > > 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.
=> Long term branches, yes, but the author should try hard to
rebase them to the top of the release/devel branch regularly.
* The merge commit on top spoils the patch set: If a set of say
three well structured patches is released, and merging creates
a conflict, the merge commit will contain just random changes
that should really be moved into the appropriate places of the
three individual commits.
* If merge commits are nested, the commit history will be a mess:
o-------------------o topic 1
/ \
o----o--o----o---------------o--o---o----o master
\ \ / /
\ o--------------o / topic 3
\ /
o-------------------o topic 2
> > CVS practive: In CVS before you can publish your work, you have
> > to update your working tree ("cvs up") and fix the merge
> > conflicts. Only a working tree that is up to date can be
> > published. The same can be done with git, although it's not
> > enforced, by using git-cherry-pick or git-am rather than
> > git-merge.
>
> Yes, but the real downside to this, which I think's more important is
> that you've now just thrown away the history by not merging. Yes, with
> git-am and friends you get a record of the commits, but you don't see where
> they came from, etc. And it's now not enough to say "look at the
> development" branch because this is rewound at various points, using your
> example.
>
> It worries me that we go to all the effort of having developers have topic
> branches, etc., only to more or less throw the history away by not merging
> them in finally, regardless of the state of the branch before the merge
> and/or with --no-ff (i.e., whether the topic branch had been rebased or
> not.)
I see your point. What I really miss in git is a mechanism to
nest commits: You have a patch set with individual commit
messages that explain the details of the set. The whole patch set
has another headline commit message that combines all the
individual patches. Something like this in fake tig output:
DV <date> * Implement feature xyz
DV <date> `-> do this
DV <date> `-> do that
DV <date> `-> something else
And you can collapse the subtree and just see
DV <date> *(3) Implement feature xyz
But I think we can have both benefits at the same time. At the
beginning we have this situation:
A---B---C---D---E master
\
b---c---d topic
Merging the topic branch into the master would give the "mess"
that I want to avoid:
A---B---C---D---E---M master
\ /
b---c---d---X topic
(M is the merge commit and X is the commit that fixes the
conflicts; actually I don't know for sure if X exists separately
or if it is just a part of M, but that does not matter here.)
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.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
