Re: Hg sure is weird!
mike.kupfer(a)xemacs.org writes:
>>>>> "ST" == Stephen J Turnbull
<stephen(a)xemacs.org> writes:
FWIW, you can use -M to suppress merge changesets. Of course, that
removes one of the clues that the changesets aren't all on the same
branch.:-/
This also suppresses merge changesets where a conflict was resolved.
That's not what I want.
It's possible that the folks on the Mercurial user list might
have
some hints for how to make this easier to deal with. Using named
branches might help. I don't have much advice because I don't
usually have to deal with branches.
I'm already using named branches. They feel substantially less
convenient than git's for reasons I don't understand yet (ie, I'm not
sure it's not insufficient RTFM), but the functionality is nearly
identical. The problem is the automatic branches and merges.
The development guidelines for the Solaris kernel and core userland
require no "merge turds". So we have tools to trim off side
branches.
You mean the repo is forced to proceed in a straight line? What
happens if you, oh, add a driver to the kernel? Does that driver's
early history just get summarized as one big patch to the kernel?
Maybe "hg log" needs an option that tells it to organize
changesets by
branch, rather than simply showing them in the same order that they
appear on disk.
I found an option for "hg log" that pretty much does what I want,
which is "hg log --follow-first". But IMO it shouldn't be an option;
it should be the only way. And it doesn't help with "hg diff".
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta