[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