On 02/13/2012 11:23 AM, Junio C Hamano wrote:
> Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:
>
>> On 02/13/2012 07:37 AM, Junio C Hamano wrote:
>>> Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:
>>>
>>>> Of *course* they operate on different namespaces. But part of the way
>>>> that revisions are selected using rev-list is by *selecting or excluding
>>>> refnames* from which it should crawl.
>>>
>>> I am appalled if that is truly the understanding of yours, after having
>>> taken more than a few patches from you to fairly core parts of Git.
>>>
>>> "rev-list A ^B" does not say "include A and exclude B from which rev-list
>>> should crawl" AT ALL. We _actively_ crawl from both A and B. It is that
>>> what are reachable from B is painted in a color different from the color
>>> in which we paint what are reachable from A.
>>
>> Please read my emails more carefully before insulting me.
>> ...
>> o---o---o---* A
>> \ \
>> \ o---o C
>> \
>> *---* B
>>
>> ... vs ...
>>
>> *---*---*---* A
>> \ \
>> \ o---o C
>> \
>> *---* B
>>
>> I argue that this is a useful selection.
>
> Then why were you so against the addition of "negation" to for-each-ref?
I'm not against it. I just think it should be spelled differently.
> If you want "I want histories reaching A and B", just say "rev-list A B",
> without adding useless "er, I do not want histories reaching C in the
> output, but I do not want commits reachable from C to be excluded from the
> output either" by mentioning C. Learn to shut your mouth and not talk
> about irrelevant "C" in such a case, and you will do just fine.
That's fine if we're talking about single references. But it does not
generalize to patterns, like my example
gitk --with-branch='refs/heads/*' \
--with-branch='remotes/gitster/*' \
--without-branch='remotes/gitster/*/**' \
--with-branch='remotes/gitster/mh/*'
If these options were supported, I could store this set of arguments as
a "view" in gitk and have it load automatically. It would continue to
work even as you add and delete branches from your repository. Listing
the branches explicitly would be fragile. Currently I would have to
write a script wrapper around gitk that invokes multiple git commands
and filters the results using grep or something. (At least I don't know
a better way.) Even if for-each-ref were taught to exclude branches, I
don't believe it is possible to use arbitrary shell commands to build a
gitk view.
> Especially, re-read your first message where you said that between
>
> git rev-list A B ^C
>
> and
>
> git rev-list $(git for-each-ref A B ^C)
>
> "consistency suggests should do the same".
I should have connected the dots better: consistency suggests they
should do the same, but they obviously cannot. Moreover, it would be
nice if the two types of exclusion could be combined in single commands,
in which case consistency is mandatory. Therefore, let's spell the
for-each-ref option another way that *can* be made consistent across
commands.
> Having said all that, if your argument against using "^" as negation for
> for-each-ref *were* with something like this from the beginning:
>
> git rev-list --all --exclude-refs=refs/tags/v\*
>
> it would have been very different. I would wholeheartedly buy the
> consistency argument that says
>
> git for-each-ref --exclude-refs=refs/tags/v\*
>
> ought to give all refs (only because for-each-ref "all" is implied) except
> for the tagged tips, and
>
> git log --all --exclude-refs=refs/tags/v\*
>
> should be the notation to produce consistently the same result as
>
> git log $(git for-each-ref --format='%(objectname)' --exclude-refs=refs/tags/v\*)
>
> but if we used "^" as negated match in for-each-ref argument, we would
> close the door to give such consistency to log family of commands later.
That *has* been exactly my argument from the beginning [1]. I
cautiously hope that we are now talking about the same thing, even if it
is not yet clear whether we agree on a conclusion.
I think this would be an interesting project, but I won't have time to
work on it in the near future. My first priority is to get the
hierarchical-refs patches rebased on top of the removal of extra refs
and do some more rationalization in that area.
Michael
[1] I don't see where anything I've written is inconsistent with your
phrasing of the argument. But fine, let's just be happy that the
miscommunication now seems to be cleared up.
--
Michael Haggerty
mhagger@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
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