Re: [Python-Dev] Commit changelog: issue number and merges
Le 09/05/2011 19:54, 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. The changesets are in the repository and there are pointers to them from the merge changeset, sure, but the data isn't in the checkout (that's how I understood pulled in to the new branch). No commit message is ever in the checkout, so I don’t follow you. If I do 'hg log' and search for a revno (that I got from hg annotate), the commit message describing the change is not attached to that revno, Ah, I understand your problem now. I would not object to a policy requiring to put helpful information in merge changesets commit messages, like “Merge fixes for # and #” or “Merge doc fixes” when there are no bug reports. I’m not sure about the “atomic” merge changesets idea that someone else expressed; I don’t think it would be that useful. nor as far as I know is there a tool that makes it easy to get from that revno to the explanatory commit message. That's what Victor and I are talking about. Is there a tool that fixes this problem? I tend to use graphical tools for history viewing. I like the GTK version of TortoiseHg, or failing that the graph displayed by “hg serve” if you enable the graphlog extension and use a browser with JavaScript. ___ 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
Re: [Python-Dev] Commit changelog: issue number and merges
Le 10/05/2011 04:51, Stephen J. Turnbull a écrit : R. David Murray writes: On Mon, 09 May 2011 18:23:45 -0500, Benjamin Petersonbenja...@python.org wrote: *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. How about the hgk extension, and hg view? http://mercurial.selenic.com/wiki/HgkExtension or, FWIW, hgview (http://www.logilab.org/project/hgview) ___ 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
Re: [Python-Dev] Commit changelog: issue number and merges
On Tue, 10 May 2011 11:51:19 +0900, Stephen J. Turnbull step...@xemacs.org wrote: R. David Murray writes: On Mon, 09 May 2011 18:23:45 -0500, Benjamin Peterson benja...@python.org wrote: *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. How about the hgk extension, and hg view? I think the problem is in my brain, not the graphical tools :) With rare exceptions I don't use tools that require a mouse to operate, though, so unless I feel like doing tcl hacking to make good keyboard bindings that particular tool won't help me anyway. 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 don't understand the issue. In my experience, hg annotate will point to the commit on the branch, not to the merge, unless there was a conflict, in which case the merge is the right place (although not necessarily the most useful place) to point. That's what I get for reasoning about hg based on my svn experience. Someone on IRC also pointed this out. I haven't done this often enough in HG for the difference to have penetrated my brain. I have a feeling I'm still going to get confused occasionally, but then I'm sure I did with svn too... -- R. David Murray http://www.bitdance.com ___ 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
Re: [Python-Dev] Commit changelog: issue number and merges
On Tue, May 10, 2011 at 12:51 PM, Stephen J. Turnbull step...@xemacs.org wrote: R. David Murray writes: On Mon, 09 May 2011 18:23:45 -0500, Benjamin Peterson benja...@python.org wrote: *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. How about the hgk extension, and hg view? http://mercurial.selenic.com/wiki/HgkExtension I don't think it's really a jump up to the graphical level that we're after. It's more a matter of: 1. Display commit message for current commit 2. Notice that this commit has two parents 3. Ignore any parent commit in the same branch as the current commit 4. For a parent commit in another branch, also display that commit message 5. If the commit in step 4 also has multiple parents, repeat from step 3 (but based off that parent commit) So a standard 3.1-3.2-default merge could be displayed along the lines of: Merge from 3.2 3.2: Merge from 3.1 3.1: Issue #123456: mod.func now works correctly when argument is negative It won't help if the last commit on the initial branch was something boring like Fix whitespace, but it will be adequate for our typical single-commit bug fix workflow. (If nobody does anything before then, I'll see what I can do with the email hook next week) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] Commit changelog: issue number and merges
On Mon, 09 May 2011 12:32:48 +0200, Victor Stinner victor.stin...@haypocalc.com wrote: 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. Would it be possible to repeat the changelog of the original commit in the merge commits? svnmerge toold prepared a nice changelog containing the changelog of all pendings commits, even when a commit was blocked. For a merge commit, I copy/paste the changelog of the original commit and I add a (Merge 3.1) prefix. I prefer to add explictly a prefix because it is not easy to notice that it is a merge commit in a python-checkins email or in the history of hg.python.org. +1. What I do is, in the edit window for the commit message, I pull in .hg/last-message.txt, and just type 'Merge' in front of my previous first line. I don't add the merge-from number, because I figure if you know which branch you are looking at you know which branch the merge came from, given that there is a strict progression. -- R. David Murray http://www.bitdance.com ___ 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
Re: [Python-Dev] Commit changelog: issue number and merges
On Mon, May 09, 2011 at 08:40:03AM -0400, R. David Murray wrote: +1. What I do is, in the edit window for the commit message, I pull in .hg/last-message.txt, and just type 'Merge' in front of my previous Thanks for this tip. I shall start following this one too. -- Senthil ___ 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
Re: [Python-Dev] Commit changelog: issue number and merges
2011/5/9 Victor Stinner victor.stin...@haypocalc.com: Hi, Commit changelogs are important to understand why the code was changed. I regulary use hg blame to search which commit introduced a particular line of code, and I am always happy if I can find an issue number because it usually contains the whole story. And since the migration to Mercurial, we have also a great tool adding a comment to an issue if the changelog contains an issue number (e.g. changelog starting with Issue #11: ...). So if someone watchs an issue (is in the nosy list), (s)he will be noticed that a related commit was pushed. It is not exactly something new: we already do that with Subversion except that today it is more automatic. I noticed that some recent commits don't contain the issue number: please try to always prefix your changelog with the issue number. It is not mandatory, but it helps me when I dig the Python history. -- 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 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. It seems like something that should be solved by tools like a display visual graph indicating what is merged. (like Bazaar) -- Regards, Benjamin ___ 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
Re: [Python-Dev] Commit changelog: issue number and merges
Le lundi 09 mai 2011 à 09:08 -0500, Benjamin Peterson a écrit : It seems like something that should be solved by tools like a display visual graph indicating what is merged. (like Bazaar) Yeah, we could fix buildbot, hg.python.org website, improve hg log, and all other tools using Mercurial. But until that, I would prefer to duplicate the information. Victor ___ 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
Re: [Python-Dev] Commit changelog: issue number and merges
On Mon, 09 May 2011 09:08:53 -0500, Benjamin Peterson benja...@python.org 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. The 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. I doubt that is going to happen. 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. -- R. David Murray http://www.bitdance.com ___ 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
Re: [Python-Dev] Commit changelog: issue number and merges
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
Re: [Python-Dev] Commit changelog: issue number and merges
On Mon, 09 May 2011 17:55:42 +0200, =?UTF-8?Q?=C3=89ric_Araujo?= mer...@netwok.org wrote: 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. The changesets are in the repository and there are pointers to them from the merge changeset, sure, but the data isn't in the checkout (that's how I understood pulled in to the new branch). If I do 'hg log' and search for a revno (that I got from hg annotate), the commit message describing the change is not attached to that revno, nor as far as I know is there a tool that makes it easy to get from that revno to the explanatory commit message. That's what Victor and I are talking about. Is there a tool that fixes this problem? (svnmerge did a nice job of that from the automate-the-message-generation end of things). -- R. David Murray http://www.bitdance.com ___ 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
Re: [Python-Dev] Commit changelog: issue number and merges
On 5/9/2011 1:54 PM, R. David Murray wrote: If I do 'hg log' and search for a revno (that I got from hg annotate), the commit message describing the change is not attached to that revno, nor as far as I know is there a tool that makes it easy to get from that revno to the explanatory commit message. That's what Victor and I are talking about. Is there a tool that fixes this problem? (svnmerge did a nice job of that from the automate-the-message-generation end of things). TortoiseSvn, and I presume TortoiseHg also, has a 'recent messages' box that makes is trivial to reuse a message. I used it with svn and will make sure to use it, if it exists, when I get started with hg. -- Terry Jan Reedy ___ 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
Re: [Python-Dev] Commit changelog: issue number and merges
2011/5/9 R. David Murray rdmur...@bitdance.com: On Mon, 09 May 2011 09:08:53 -0500, Benjamin Peterson benja...@python.org 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. The 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. I doubt that is going to happen. *cough* http://mercurial.selenic.com/wiki/GraphlogExtension 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? -- Regards, Benjamin ___ 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
Re: [Python-Dev] Commit changelog: issue number and merges
On Mon, 09 May 2011 18:23:45 -0500, Benjamin Peterson benja...@python.org wrote: 2011/5/9 R. David Murray rdmur...@bitdance.com: On Mon, 09 May 2011 09:08:53 -0500, Benjamin Peterson benja...@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 ___ 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
Re: [Python-Dev] Commit changelog: issue number and merges
R. David Murray writes: On Mon, 09 May 2011 18:23:45 -0500, Benjamin Peterson benja...@python.org wrote: *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. How about the hgk extension, and hg view? http://mercurial.selenic.com/wiki/HgkExtension 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 don't understand the issue. In my experience, hg annotate will point to the commit on the branch, not to the merge, unless there was a conflict, in which case the merge is the right place (although not necessarily the most useful place) to point. ___ 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
