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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

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.

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".  Should the consistency also
suggest that

    git rev-list $(git rev-parse A B ^C)

do the same?  That is a total bullshit that can only come from somebody
who does not understand the distinction between pattern matching in
refnames vs set operation over commit DAG.

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.

But that wasn't what you said.  Why should I get accused of not guessing
what you meant to say but you clearly didn't, and in addition blamed for
insulting merely for pointing out the idiocy in what you said?

No. *YOU* go back and re-read your message more carefully.


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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]