[Python-Dev] Commit changelog: issue number and merges

[R. David Murray]

On Mon, 09 May 2011 18:23:45 -0500, Benjamin Peterson <benjamin at python.org> wrote:
> 2011/5/9 R. David Murray <rdmurray at bitdance.com>:
> > On Mon, 09 May 2011 09:08:53 -0500, Benjamin Peterson <benjamin at python.or=
> g> wrote:
> >> I thought the whole point of merging was that you brought a changeset
> >> from one branch to another. This why I just write "merge" because
> >> otherwise you're technically duplicating information that is pulled
> >> onto the branch by merging.
> >
> > No it isn't. =C2=A0The commit message isn't pulled into the new branch.
> >
> >> It seems like something that should be solved by tools like a display
> >> visual graph indicating what is merged. (like Bazaar)
> >
> > You'd need some extension to hg log that would show the original commit
> > message for the first changeset in the merge line in order to "fix"
> > this. =C2=A0I doubt that is going to happen.
> 
> *cough* http://mercurial.selenic.com/wiki/GraphlogExtension

I'm sorry, but I've looked at the output of that and the mental overhead
has so far proven too high for it to be of any use to me.  I apologize for
not having made the full mental transition to "distributed VCS"/DAG
(apparently), but it sounds like I'm not the only one....

> > Note that saying just 'merge' makes perfect sense when you are pulling
> > in a whole group of changesets in order to synchronize two branches.
> > But if you are applying a single changeset to multiple branches,
> > as we often do in our workflow, then I think duplicating the commit
> > message is (1) easy to do and (2) very helpful when looking at
> > hg log output.
> 
> What's the difference between pulling multiple changesets in and one then?

I'm talking about merging trunk to a feature branch, for example.
I'd not expect any message other than 'merge' for that.

I'd be satisfied if the commit messages listed the issue numbers involved
in the merge, especially if someone (like Éric) is merging more than
one change at a time.

But as I think about this, frankly I'd rather see atomic commits, even
on merges.  That was something I disliked about svnmerge, the fact that
often an svnmerge commit involved many changesets from the other branch.
That was especially painful in exactly the same situation:  trying to
backtrack a change starting from 'svn blame'.  I limited my own use
of multiple-changeset-svnmerge to doc changes and changesets that were
actually related, despite the overhead involved in doing it that way.

All that said, I'm not trying to impose my will on the workflow, I'll
certainly live with the consensus (though unless there is an outcry
against it I'll continue putting the full commit message in my own
merges).

--
R. David Murray           http://www.bitdance.com