Hi,
Le 09/05/2011 16:08, Benjamin Peterson a écrit :
2011/5/9 Victor Stinner <victor.stin...@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.
Regards
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
