Jeff King writes:
> 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
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 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
On Thu, May 25, 2017 at 5:27 PM, Jeff King wrote:
> git log :/foo.*bar
Another option would be to deprecate the :/rx syntax over some period
in favor of ^{/rx}.
I think it's too ugly to live, and really useless. It's equivalent to
"--grep= --all". Does anyone use this and
On Fri, May 26, 2017 at 11:13:55AM +0900, Junio C Hamano wrote:
> >- git log :^foo
> > (when "^foo" exists in your index)
> >
> > The same logic applies; it would continue to work. And
> > ditto for any other weird filenames in your index like
> > "(attr)foo".
>
>
Jeff King writes:
> But let's consider related invocations and whether we're
> making them better or worse:
>
>- git log :/foo
> (when "foo" matches a commit message)
>
> This one should remain the same. Like the existing
> wildcard rule, we're touching only
For commands that take revisions and pathspecs, magic
pathspecs like ":^Documentation" or ":/Documentation" have
to appear on the right-hand side of the disambiguating "--",
like:
git log -- :^Documentation
This makes them more annoying to use than they need to be.
We loosened the rules for
6 matches
Mail list logo