On Thu, 18 Oct 2018 at 05:23, Junio C Hamano <gitster@xxxxxxxxx> 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". > > 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. > > 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 > > that will result in an empty set if we accept the change proposed > here but make it unconditional? If so "This and future versions of > Git will honor the --default even when there are other revisions > given on the command line, as long as they are ALL negative ones. > This is a backward incompatibile change, but you can update your > scripts with '--no-default' if you do not like the new behaviour" in > the release notes may be a viable alternative way forward. That would certainly work for me. Andreas > If there is no such way in the released versions of Git, then that > would not work, and a strict opt-in like the approach taken by the > proposed patch would become necessary.
