[Python-Dev] Commit changelog: issue number and merges (original) (raw)

R. David Murray rdmurray at bitdance.com
Tue May 10 03:32:46 CEST 2011

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

More information about the Python-Dev mailing list