Re: Suggestion: make --left-right work with --merge

Junio C Hamano writes:

Doesn't

	git rev-parse --revs-only --no-flags "$@" | grep '^[0-9a-f]'

give you what you want?

Well, it does, except for --merge, which is perhaps a special case.

(Actually, what would git rev-parse --revs-only --no-flags output that
isn't a SHA1 ID?  Why do you have the grep command there?)

Also, --left-right with symmetric difference is an interesting case,
because git rev-parse will turn a symmetric difference into three SHA1
IDs, with the 3rd one negated.  If I pass what I get from git
rev-parse to git log --left-right, then git log doesn't recognize that
as a symmetric difference and shows all commits with the ">" marker.

Interesting.

 * gitk has already done what the user asked once.  E.g. "git
   log next..master" to find out new trivially correct fixes
   that are already applied to 'master' and will be brought to
   'next' when I merge 'master' to 'next' next time;

 * The user does "git merge master" while on 'next', and tell
   gitk to "Update".

 * gitk is expected to re-run "git log next..master" (textually
   the same command line), but most part of the graph it already
   knows about.  You need a way to omit what you already know,
   so when you run the query for the first time you would want
   to remember the actual object names, so that you use them to
   tweak the query to "git log next..master --not <positive ones
   in the first round>" for the second query.

In the above example, the set of commits actually will shrink
('next' moves and you will exclude more than before upon
"Update").

"Update" adds new commits and moves the head/tag markers as necessary,
but doesn't remove commits from the graph, because that's a bit hard.
There is also a "Reload" function that restarts from scratch and so
will not show the newly-removed commits (i.e., the same as "Update"
does now in current gitk master), but it is a lot slower than
"Update".  In the common case (a few commits added), "Update" takes
less than a second.

If you are only interested in cases that the only positive end
grows (in the above example, the user adds commit to 'master'
instead of merging it into 'next'), then grabbing only the
positive ends (e.g. 'master' in 'next..master'), negate them and
append them to the original query would speed things up, but
obviously that would not work in the above example.

That's essentially what I do.  I think I'll just have to do special
cases for --merge and --left-right.

Paul.