Pasky wrote:
> But what I said still holds - this can go
> in only after we have a shell library sharing the common functions
Ah - thanks for repeating that - it didn't sink in the first time.
Good idea.
> Yes, sorry about that; I had a lot of mail traffic lately ...
No problem. I hope you're
ely and I'm not so
used to it. ;-)
> 1) How do you want me to fix the indentation on my patch
> to optimize gitdiff-do script:
> - forget my first patch and resend from scratch, or
> - a second patch restoring indentation, on top of my first one.
Resend from scratch,
Pasky,
Looks like a couple of questions I asked over the weekend
got lost along the way.
1) How do you want me to fix the indentation on my patch
to optimize gitdiff-do script:
- forget my first patch and resend from scratch, or
- a second patch restoring indentation, on top
Petr wrote:
> Please don't reindent the scripts. It violates the current coding style
> and the patch is unreviewable.
Sorry - I had not realized that there was a style in this case.
I am all in favor of such coding styles, and will gladly fit this one.
Do you want the patch resent, or a patch t
Dear diary, on Sun, Apr 17, 2005 at 01:28:04AM CEST, I got a letter
where Paul Jackson <[EMAIL PROTECTED]> told me that...
> Reduce number of subcommands execv'd by a
> third, by only calling 'rm' once, at end, not each
> loop.
The idea behind that was that diffing could take a significant portion
Rewrite gitdiff-do so that it works with arbitrary
whitespace (space, tab, newline, ...) in filenames.
Reduce number of subcommands execv'd by a
third, by only calling 'rm' once, at end, not each
loop.
Avoid using shell arrays; perhaps more portable.
Avoid 'echo -e' when displaying names; dont e
6 matches
Mail list logo
