Re: [RFC/PATCH] tag: make list exclude !<pattern>

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Feb 13, 2012, 14:34 UTC
Message-ID: <4F391F5C.1000400@alum.mit.edu>
In-Reply-To: <7v4nuvghfk.fsf@alter.siamese.dyndns.org>

On 02/13/2012 11:23 AM, Junio C Hamano wrote:

Show 36 quoted lines

> Michael Haggerty <mhagger@alum.mit.edu> writes:
> 
>> On 02/13/2012 07:37 AM, Junio C Hamano wrote:
>>> Michael Haggerty <mhagger@alum.mit.edu> 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.

Show 5 quoted lines

> 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.

Show 9 quoted lines

> 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.

Show 21 quoted lines

> 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@alum.mit.edu
http://softwareswirl.blogspot.com/