On Sat, May 27, 2017 at 11:54:07AM +0200, Ævar Arnfjörð Bjarmason wrote:
> On Thu, May 25, 2017 at 5:27 PM, Jeff King <p...@peff.net> wrote:
> > git log :/foo.*bar
>
> Another option would be to deprecate the :/rx syntax over some period
> in favor of ^{/rx}.
Yeah, the latter is more flexible (can start at a tip of your choosing)
and syntactically matches other object selectors much better.
> I think it's too ugly to live, and really useless. It's equivalent to
> "--grep=<rx> --all". Does anyone use this and not really mean to use
> ^{/rx}? E.g. "git show :/fix" might show a fix on some unrelated
> branch you recently rebased.
It's actually _worse_ than that --grep because it only picks one result.
So not only do we look at unrelated branches, but they may take
precedence (based on commit timestamp) over the current branch.
It is shorter than "HEAD^{/re}", though. So I suspect people do use it
and would be slightly annoyed if it went away.
> > will be treated as a pathspec (if it doesn't match a
> > commit message) due to the wildcard matching in
> > 28fcc0b71.
>
> So it might DWYM after hanging there looking at your entire history
> for a commit message matching foo.*bar? And if you make such a commit
> it'll start meaning something else entirely?
Yeah. That's a good reason not to use ":/" without a disambiguating "--"
(which _does_ work, even without my series, because check_filename()
does specific path-matching). At best, you pay for a complete useless
history traversal before the command actually starts running. But much
more likely is that Git just complains of ambiguity, because people tend
to mention top-level paths in their commit messages. E.g.:
$ cd t
$ git grep foo :/Documentation
fatal: ambiguous argument ':/Documentation': both revision and filename
So it really is a pretty horrible syntax.
-Peff
