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

[Paul Mackerras <paulus@samba.org>]

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.