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

R. David Murray rdmurray at bitdance.com
Tue May 10 14:50:34 CEST 2011


On Tue, 10 May 2011 11:51:19 +0900, "Stephen J. Turnbull" <stephen at xemacs.org> wrote:
> R. David Murray writes:
>  > On Mon, 09 May 2011 18:23:45 -0500, Benjamin Peterson <benjamin at 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


More information about the Python-Dev mailing list