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

Éric Araujo merwok at netwok.org
Mon May 9 17:55:42 CEST 2011


 Le 09/05/2011 16:08, Benjamin Peterson a écrit :
> 2011/5/9 Victor Stinner <victor.stinner at haypocalc.com>:
>> For merge commits: many developers just write "merge" or "merge 
>> 3.1". I
>> have to go to the parent commit (and something to the grandparent,
>> 3.1->3.2->3.3) to learn more about the commit.

 I follow conventions I’ve seen elsewhere (maybe Mercurial itself): I 
 use “Branch merge” when I merge anonymous branches on the same named 
 branch, and “Merge x.y” for forward-porting across named branches.

 I also tend to do more than one commit before merging.  It would not be 
 very easy with my current toolchain to get the commit message(s) to 
 insert into the new message, and I think it’s not necessary.

> 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.

 +1.  No interest in manually duplicating available information.

 Le 09/05/2011 17:44, R. David Murray a écrit :
> No it isn't.  The commit message isn't pulled into the new branch.

 Sorry, your terminology does not make sense.  If you mean that the 
 commit message is not reused in the new commit after the merge, it’s 
 true.  However, the commit message with the relevant information is 
 available as part of the changesets that have been pulled and merged.


More information about the Python-Dev mailing list