Re: [PATCH 2/4] add -u: get rid of "treewideupdate" configuration

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH 2/4] add -u: get rid of "treewideupdate" configuration

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:51:00

Nguyen Thai Ngoc Duy [off-list ref] writes:
The intention is good, but reality may need more work.
Yes, I knew about "add -u", as I was touching in its neighbourhood
recently.  The way "git grep" does this may be more appropriate as a short
term solution.

The updated init_pathspec() should at least take (prefix, argc, argv[]),
and in addition a hint as to what to do when there is no pathspec from the
command line (i.e. argc == 0), so that it can behave differently when the
user gave only ":".

By the way, the field in "struct pathspec_item" would need to be updated,
and the matcher would need to be changed, so that each item knows up to
which part of the "match" string came from the prefix (and remainder is a
user supplied pattern).  Then from a subdirectory a?a/bbb,

  - "c" should parse into prefix "a?a/bbb/" plus pattern "c"

  - ":../c" should become prefix "a?a/" plus pattern "c"

and the matcher should match the prefix part _literally_ without
fnmatch(3), while using whatever magic (e.g. use_wildcard) to match the
pattern part.  I think we currently match the whole thing with fnmatch(3),
which in practice may be OK only because not many people use glob
characters in their directory names, but what the current matcher does
logically is wrong.

Of course, both of the above are tasks after 1.7.5 ships, but I thought I
should mention them now, as you seem to be already thinking about the
future.

Re: [PATCH 2/4] add -u: get rid of "treewideupdate" configuration

From: Nguyen Thai Ngoc Duy <hidden>
Date: 2016-06-15 22:51:00

On Sat, Apr 9, 2011 at 12:20 PM, Junio C Hamano [off-list ref] wrote:
By the way, the field in "struct pathspec_item" would need to be updated,
and the matcher would need to be changed, so that each item knows up to
which part of the "match" string came from the prefix (and remainder is a
user supplied pattern).  Then from a subdirectory a?a/bbb,

 - "c" should parse into prefix "a?a/bbb/" plus pattern "c"

 - ":../c" should become prefix "a?a/" plus pattern "c"

and the matcher should match the prefix part _literally_ without
fnmatch(3), while using whatever magic (e.g. use_wildcard) to match the
pattern part.  I think we currently match the whole thing with fnmatch(3),
which in practice may be OK only because not many people use glob
characters in their directory names, but what the current matcher does
logically is wrong.
OK. Let's add nomagic_len (or plain_len) to pathspec_item for that. I
was thinking of noglob_len but changed my mind because the same can
also be applied for icase magic. We don't want to do strcasecmp on
prefix.
Of course, both of the above are tasks after 1.7.5 ships, but I thought I
should mention them now, as you seem to be already thinking about the
future.
-- 
Duy
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help