Re: [PATCH] builtin/tag.c: return appropriate value when --points-at finds an empty list

mething else instead of `[[ -z ]]` in the script. But I see what you're saying... -- /ΓΠ On Mon, Dec 11, 2017 at 4:05 PM, Derrick Stolee wrote: > On 12/11/2017 8:44 AM, George Papanikolaou wrote: >> >> `git tag --points-at` can simply return if the given rev does not have >

[PATCH] builtin/tag.c: return appropriate value when --points-at finds an empty list

`git tag --points-at` can simply return if the given rev does not have any tags pointing to it. It's not a failure but it shouldn't return with 0 value. --- builtin/tag.c | 4 1 file changed, 4 insertions(+) diff --git a/builtin/tag.c b/builtin/tag.c index b38329b59..68b84db2a 100644 --- a/b

Re: [PATCH] builtin/apply.c: use iswspace() to detect line-ending-like chars

On Tue, Mar 25, 2014 at 6:54 AM, Junio C Hamano wrote: > As a tangent, I have a suspicion that the current implementation may > be wrong at the beginning of the string. Wouldn't it match " abc" > and "abc", even though these two strings shouldn't match? Wouldn't that be accomplished by just remo

Re: [PATCH] builtin/apply.c: use iswspace() to detect line-ending-like chars

On Sat, Mar 22, 2014 at 12:46 AM, Eric Sunshine wrote: > > Because it's unnecessary and invites confusion from people reading the > code since they now have to wonder if there is something unusual and > non-obvious going. Worse, the two loops immediately below the ones you > changed, as well as th

[PATCH] builtin/apply.c: use iswspace() to detect line-ending-like chars

Removing the bloat of checking for both '\r' and '\n' with the prettier iswspace() function which checks for other characters as well. (read: \f \t \v) --- This is one more try to clean up this fuzzy_matchlines() function as part of a microproject for GSOC. The rest more clarrified microprojects w

Re: [PATCH] builtin/apply.c: fuzzy_matchlines:trying to fix some inefficiencies

Hi, Thanks for the feedback, On Thu, Mar 20, 2014 at 11:58 AM, Michael Haggerty wrote: > > Why is this an improvement? Do you expect this function to be called > often for empty lines (as opposed, for example, to lines consisting > solely of whitespace characters)? > Yes, you are probably right

[PATCH] builtin/apply.c: fuzzy_matchlines:trying to fix some inefficiencies

Hi again guys, I forgot to add the signed-of line to the tiny patch I sent earlier for GSOC. Any ideas about the changes? Thanks... Signed-off-by: George Papanikolaou --- builtin/apply.c | 25 + 1 file changed, 9 insertions(+), 16 deletions(-) diff --git a/builtin

[PATCH] builtin/apply.c: fuzzy_matchlines:trying to fix some inefficiencies

Hi fellows, I'm planning on applying on GSOC 2014... I tried my luck with that kinda weird microproject about inefficiencies, and I think I've discovered some. (also on a totally different mood, there are some warning about empty format strings during compilation that could easily be silenced wit

mv/rm submodules

Hi list, I was just playing with the new features of 'git mv' in 1.8.5 and realized that both rm and mv don't change the .git/config file. Is that on purpuse? Also after mv you need to run 'submodule update' and I think this should be documented somewhere. Thanks.. -- George 'papanikge' Papanik