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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
