Re: [RFC] revision: Add --sticky-default option

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

 



On Thu, Oct 18, 2018 at 12:23:26PM +0900, Junio C Hamano wrote:

> Jeff King <peff@xxxxxxxx> writes:
> 
> > I'd probably call it something verbose and boring like
> > --use-default-with-uninteresting or --default-on-negative.
> > I dunno.
> 
> These two names are improvement, but there needs a hint that the
> change we are interested in is to use default even when revs are
> given as long as ALL of them are negative ones.  Which in turn means
> there is NO positive ones given.
> 
> So perhaps "--use-default-without-any-positive".

Yeah, though that's getting pretty long. Another way is probably to say
"only" more clearly. Like "--default-on-only-negative" or something.

> Having said that, I have to wonder how serious a breakage we are
> going to cause to established users and scripts if we made this
> change without any explicit option.  After all, it would be rather
> obvious that people will get a history with some commits (or none at
> all) when they were expecting no output that the "default behaviour"
> has changed.  I also wonder how would scripts take advantage of the
> current "defeat --default as soon as we see any rev, even a negative
> one"---in short, I am not sure if the theoretical regression this
> new "option" is trying to avoid is worth avoiding in the first
> place.

Just to play devil's advocate, how about this:

  git log --branches=jk/* --not origin/master

Right now that shows nothing if there are no matching branches. But I
think under the proposed behavior, it would start showing HEAD, which
seems counter-intuitive.

Or are we going to count any positive selector as a positive ref, even
if it matches nothing? I could buy that, though it means that the
command above is subtly different from one or both of:

  branches() {
    git for-each-ref --format='%(refname)' refs/heads/jk/*
  }

  # is --stdin a selector, too?
  branches | git log --stdin --not origin/master

  # here we have no idea that the user did a query and must show HEAD
  git log $(branches) --not origin/master

> Is there a way to say "usually this command has built-in --default=HEAD
> behaviour, but I am declining that" already, i.e. 
> 
>     $ git log --no-default $REVS

I don't think we have that, but regardless of this patch, it seems like
a potentially useful thing. I think we mostly get around it by the fact
that scripts ought to be using "rev-list", and it does not have such a
default that needs to be overridden.

-Peff



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

  Powered by Linux