On Wed, Feb 10, 2016 at 09:35:46AM -0800, Junio C Hamano wrote:
> > IOW, something like this implements the "permissive" thing I wrote above
> > (i.e., be inclusive when seeing if something could plausibly be a
> > filename, but exclusive when complaining that it _could_ be one):
>
> Yup, I think
Jeff King writes:
> Yes, because ":/" is treated specially in check_filename(), and avoids
> kicking in the wildcard behavior. That is certainly preferring revs to
> pathspecs, but I think preferring one over the other is preferable to
> barfing. If the user wants carefulness, they should use "--
On Tue, Feb 09, 2016 at 12:37:32PM -0800, Junio C Hamano wrote:
> I was leaning towards merging this version, but I became unsure
> while writing an entry for "What's cooking" (which will be used as a
> merge summary message and then will appear in the Release Notes).
>
> We would surely want
>
On Mon, Feb 08, 2016 at 02:36:32PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > But having looked at this, I can't help but wonder if the rule should
> > not be "does the file exist" in the first place, but "is the file in the
> > index". This dwimmery is about commands like "log" that
Jeff King writes:
> Subject: [PATCH] check_filename: tighten requirements for dwim-wildcards
>
> Commit 28fcc0b (pathspec: avoid the need of "--" when
> wildcard is used, 2015-05-02) introduced a convenience to
> our dwim-parsing: when "--" is not present, we guess that
> items with wildcard char
Jeff King writes:
> But having looked at this, I can't help but wonder if the rule should
> not be "does the file exist" in the first place, but "is the file in the
> index". This dwimmery is about commands like "log" that are reading
> existing commits. I cannot think of a case where we would wa
On Mon, Feb 08, 2016 at 03:20:43PM -0500, Jeff King wrote:
> On Mon, Feb 08, 2016 at 02:52:30PM -0500, Jeff King wrote:
>
> > Here is my patch again, with that part removed, and the tests fixed up.
> > Though on reflection, I do think it would be better if we could simply
> > expand the wildcard
On Mon, Feb 08, 2016 at 02:52:30PM -0500, Jeff King wrote:
> Here is my patch again, with that part removed, and the tests fixed up.
> Though on reflection, I do think it would be better if we could simply
> expand the wildcard globs to say "does this match anything in the file
> system". That mak
On Mon, Feb 08, 2016 at 11:35:10AM -0800, Junio C Hamano wrote:
> To be bluntly honest, I do not see the current "string containing
> wildcard characters are taken as path, not rev, unless you use the
> double dash to disambiguate." all bad. Isn't it sort of crazy to
> have square brackets in pat
Jeff King writes:
> The patch for that might look like this. I like it for its relative
> simplicity, though it does make the rules even harder to explain to a
> user...
True.
To be bluntly honest, I do not see the current "string containing
wildcard characters are taken as path, not rev, unles
On Mon, Feb 08, 2016 at 09:15:52AM -0500, Jeff King wrote:
> I wonder if we could fix this pretty simply, though, by skipping the
> "does it have a wildcard" check when we see a colon in the path. That is
> a good indication that we are using one of git's special rev syntaxes
> (either "tree:path"
On Mon, Feb 08, 2016 at 09:15:52AM -0500, Jeff King wrote:
> I wonder if we could fix this pretty simply, though, by skipping the
> "does it have a wildcard" check when we see a colon in the path. That is
> a good indication that we are using one of git's special rev syntaxes
> (either "tree:path"
On Mon, Feb 08, 2016 at 12:06:44PM +0700, Duy Nguyen wrote:
> On Sun, Feb 7, 2016 at 10:11 PM, Kirill Likhodedov
> wrote:
> > Hi Duy,
> >
> >> It's from 28fcc0b (pathspec: avoid the need of "--" when wildcard is
> >> used - 2015-05-02)
> >
> > v2.5.0 is the first release which contains 28fcc0b.
>
On Sun, Feb 7, 2016 at 10:11 PM, Kirill Likhodedov
wrote:
> Hi Duy,
>
>> It's from 28fcc0b (pathspec: avoid the need of "--" when wildcard is
>> used - 2015-05-02)
>
> v2.5.0 is the first release which contains 28fcc0b.
> I can confirm that older versions of Git work correctly without “--“:
>
> #
Hi Kirill,
On Sun, 7 Feb 2016, Kirill Likhodedov wrote:
> > On 06 Feb 2016, at 19:10 , Johannes Schindelin
> > wrote:
> >
> > git show 'HEAD:bra[ckets].txt' --
> >
>
> Nice catch! It works for me even without quotes.
Only by chance. Once you have a HEAD:brat.txt file in the current work
Hi Duy,
> It's from 28fcc0b (pathspec: avoid the need of "--" when wildcard is
> used - 2015-05-02)
v2.5.0 is the first release which contains 28fcc0b.
I can confirm that older versions of Git work correctly without “--“:
# /opt/local/bin/git version
git version 1.7.1.1
# /opt/local/bin/git show
Hi Johannes,
> On 06 Feb 2016, at 19:10 , Johannes Schindelin
> wrote:
>
> git show 'HEAD:bra[ckets].txt' --
>
Nice catch! It works for me even without quotes. Although this “--“ is
mentioned in the error message, I didn’t even try since its meaning is totally
unrelated with the probl
On Sat, Feb 6, 2016 at 11:10 PM, Johannes Schindelin
wrote:
> Hi Kirill,
>
> On Sat, 6 Feb 2016, Kirill Likhodedov wrote:
>
>> > On 06 Feb 2016, at 17:21 , Johannes Schindelin
>> > wrote:
>> >
>> > This is expected behavior of the Bash you are using. The commands that I
>> > think would reflect
Hi Kirill,
On Sat, 6 Feb 2016, Kirill Likhodedov wrote:
> > On 06 Feb 2016, at 17:21 , Johannes Schindelin
> > wrote:
> >
> > This is expected behavior of the Bash you are using. The commands that I
> > think would reflect your intentions would be:
> >
> > git init brackets
> > cd bra
Hi Johannes,
thanks for your answer, but unfortunately it doesn’t help.
> On 06 Feb 2016, at 17:21 , Johannes Schindelin
> wrote:
>
> This is expected behavior of the Bash you are using. The commands that I
> think would reflect your intentions would be:
>
> git init brackets
> cd
Hi Kirill,
On Sat, 6 Feb 2016, Kirill Likhodedov wrote:
> Is it a bug or I just didn’t find the proper way to escape the brackets?
>
> Steps to reproduce:
>
> git init brackets
> cd brackets/
> echo ‘asd’ > bra[ckets].txt
> git add bra\[ckets\].txt
> git commit -m initial
>
I’ve faced a problem that `git show :` returns an error when
contains square brackets.
Interestingly, the problem is reproducible on "GNU bash, version
3.2.57(1)-release (x86_64-apple-darwin15)", but not on "zsh 5.0.7
(x86_64-pc-linux-gnu)”. The problem is also reproducible when called from a
22 matches
Mail list logo
