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