Re: [PATCH] apply: use strcmp(3) for comparing strings in gitdiff_verify_name()

René Scharfe writes: > I wonder when we can begin to target C99 in git's source, though. :) Let's get the ball rolling by starting to use some of the useful features like designated initializers, perhaps, in a small, critical and reasonably stable part of the system that anybody

Re: [PATCH] apply: use strcmp(3) for comparing strings in gitdiff_verify_name()

Am 09.07.2017 um 14:37 schrieb Andreas Schwab: On Jul 09 2017, René Scharfe wrote: [2] http://pubs.opengroup.org/onlinepubs/009695399/functions/memchr.html You are using an old revision. OK, the final draft of C11 [3] says "The implementation shall behave as if it reads the

Re: [PATCH] apply: use strcmp(3) for comparing strings in gitdiff_verify_name()

On Jul 09 2017, René Scharfe wrote: > [2] http://pubs.opengroup.org/onlinepubs/009695399/functions/memchr.html You are using an old revision. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for

Re: [PATCH] apply: use strcmp(3) for comparing strings in gitdiff_verify_name()

Am 09.07.2017 um 00:29 schrieb Junio C Hamano: René Scharfe writes: Am 08.07.2017 um 13:08 schrieb Ramsay Jones: On 08/07/17 09:58, René Scharfe wrote: Avoid running over the end of another -- a C string whose length we don't know -- by using strcmp(3) instead of memcmp(3) for

Re: [PATCH] apply: use strcmp(3) for comparing strings in gitdiff_verify_name()

Am 08.07.2017 um 15:38 schrieb Andreas Schwab: On Jul 08 2017, René Scharfe wrote: Am 08.07.2017 um 13:08 schrieb Andreas Schwab: On Jul 08 2017, René Scharfe wrote: Avoid running over the end of another -- a C string whose length we don't know -- by using

Re: [PATCH] apply: use strcmp(3) for comparing strings in gitdiff_verify_name()

René Scharfe writes: > Am 08.07.2017 um 13:08 schrieb Ramsay Jones: >> On 08/07/17 09:58, René Scharfe wrote: >>> Avoid running over the end of another -- a C string whose length we >>> don't know -- by using strcmp(3) instead of memcmp(3) for comparing it >>> with another C

Re: [PATCH] apply: use strcmp(3) for comparing strings in gitdiff_verify_name()

On Jul 08 2017, René Scharfe wrote: > Am 08.07.2017 um 13:08 schrieb Andreas Schwab: >> On Jul 08 2017, René Scharfe wrote: >> >>> Avoid running over the end of another -- a C string whose length we >>> don't know -- by using strcmp(3) instead of memcmp(3) for

Re: [PATCH] apply: use strcmp(3) for comparing strings in gitdiff_verify_name()

Am 08.07.2017 um 13:08 schrieb Ramsay Jones: On 08/07/17 09:58, René Scharfe wrote: Avoid running over the end of another -- a C string whose length we don't know -- by using strcmp(3) instead of memcmp(3) for comparing it with another C string. I had to read this twice, along with the patch

Re: [PATCH] apply: use strcmp(3) for comparing strings in gitdiff_verify_name()

Am 08.07.2017 um 13:08 schrieb Andreas Schwab: On Jul 08 2017, René Scharfe wrote: Avoid running over the end of another -- a C string whose length we don't know -- by using strcmp(3) instead of memcmp(3) for comparing it with another C string. That's not a good justification

Re: [PATCH] apply: use strcmp(3) for comparing strings in gitdiff_verify_name()

ame); > char *another; > if (isnull) > return error(_("git apply: bad git-diff - expected > /dev/null, got %s on line %d"), >*name, state->linenr); > another = find_name(s

Re: [PATCH] apply: use strcmp(3) for comparing strings in gitdiff_verify_name()

On Jul 08 2017, René Scharfe wrote: > Avoid running over the end of another -- a C string whose length we > don't know -- by using strcmp(3) instead of memcmp(3) for comparing it > with another C string. That's not a good justification for the change, since memcmp never reads past

[PATCH] apply: use strcmp(3) for comparing strings in gitdiff_verify_name()

isnull) return error(_("git apply: bad git-diff - expected /dev/null, got %s on line %d"), *name, state->linenr); another = find_name(state, line, NULL, state->p_value, TERM_TAB); - if (!another || memcmp(a

[PATCH v2 7/7] reflog-walk: apply --since/--until to reflog dates

When doing a reflog walk, we use the commit's date to do any date limiting. In earlier versions of Git, this could lead to nonsense results, since a skipped commit would truncate the traversal. So a sequence like: git commit ... git checkout week-old-branch git checkout - git log -g

[PATCH] apply: use starts_with() in gitdiff_verify_name()

ply_state *state, } free(another); } else { - /* expect "/dev/null" */ - if (memcmp("/dev/null", line, 9) || line[9] != '\n') + if (!starts_with(line, "/dev/null\n")) retu

Re: [PATCH 2/2] apply: handle assertion failure gracefully

René Scharfe <l@web.de> writes: > Hmm, pondering that, it seems I forgot to reset its value after each > patch. Or better just move it into struct patch, next to the extension > bits: Good catch. > -- >8 -- > Subject: fixup! apply: check git diffs for mutuall

Re: [PATCH 2/2] apply: handle assertion failure gracefully

Am 27.06.2017 um 20:08 schrieb Junio C Hamano: > René Scharfe <l@web.de> writes: > >> Thought a bit more about it, and as a result here's a simpler approach: >> >> -- >8 -- >> Subject: [PATCH] apply: check git diffs for mutually exclusive header lines &g

Re: [PATCH 2/2] apply: handle assertion failure gracefully

René Scharfe <l@web.de> writes: > Thought a bit more about it, and as a result here's a simpler approach: > > -- >8 -- > Subject: [PATCH] apply: check git diffs for mutually exclusive header lines > > A file can either be added, removed, copied, or renamed, but no

Re: [PATCH 2/2] apply: handle assertion failure gracefully

Am 25.02.2017 um 11:13 schrieb Vegard Nossum: > For the patches in the added testcases, we were crashing with: > > git-apply: apply.c:3665: check_preimage: Assertion `patch->is_new <= 0' > failed. > diff --git a/t/t4154-apply-git-header.sh b/t/t4154-apply-git-header

Re: [PATCH 1/2] apply: guard against renames of non-existant empty files

>>> if ((!patch->is_delete && !patch->new_name) || >>> (!patch->is_new&& !patch->old_name)) { >>> >> >> Yes, probably. So let's actually do it! -- >8 -- Subject: [PATCH] apply: check git diffs for

Re: [PATCH 2/2] apply: handle assertion failure gracefully

>>>>>> diff --git a/apply.c b/apply.c >>>>>> index cbf7cc7f2..9219d2737 100644 >>>>>> --- a/apply.c >>>>>> +++ b/apply.c >>>>>> @@ -3652,7 +3652,6 @@ static int check_preimage(struct apply_state >>>>

Re: [PATCH v4 2/5] stash: Add a test for when apply fails during stash branch

9fb05ca 100755 >> --- a/t/t3903-stash.sh >> +++ b/t/t3903-stash.sh >> @@ -656,6 +656,20 @@ test_expect_success 'stash branch should not drop the >> stash if the branch exists >> git rev-parse stash@{0} -- >> ' >> >> +test_expect_success 'stash b

Re: [PATCH v4 2/5] stash: Add a test for when apply fails during stash branch

hould not drop the > stash if the branch exists > git rev-parse stash@{0} -- > ' > > +test_expect_success 'stash branch should not drop the stash if the apply > fails' ' > + git stash clear && > + git reset HEAD~1 --hard && > + echo foo

[PATCH v4 2/5] stash: Add a test for when apply fails during stash branch

stash if the apply fails' ' + git stash clear && + git reset HEAD~1 --hard && + echo foo >file && + git add file && + git commit -m initial && + echo bar >file && + git stash && +

Re: [PATCH 2/2] rebase -i: silence stash apply

gt; stash_sha1=$(cat "$state_dir/autostash") > if git stash apply $stash_sha1 2>&1 >/dev/null > then > echo "$(gettext 'Applied autostash.')" > else >

Re: [PATCH 2/2] rebase -i: silence stash apply

+++ b/sequencer.c @@ -1914,6 +1914,8 @@ static int apply_autostash(struct replay_opts *opts) strbuf_trim(_sha1); child.git_cmd = 1; + child.no_stdout = 1; + child.no_stderr = 1; argv_array_push(, "stash"); argv_array_push(, "apply");

Re: [PATCH 2/2] rebase -i: silence stash apply

pply_autostash(struct replay_opts *opts) > strbuf_trim(_sha1); > > child.git_cmd = 1; > + child.no_stdout = 1; > + child.no_stderr = 1; > argv_array_push(, "stash"); > argv_array_push(, "apply"); > argv_array_push(,

[PATCH 2/2] rebase -i: silence stash apply

From: Phillip Wood <phillip.w...@dunelm.org.uk> The shell version of rebase -i silences the status output from 'git stash apply' when restoring the autostashed changes. The C version does not. Having the output from git stash apply on the screen is distracting as it makes it difficult t

[PATCH v2] i18n patches to apply for rc2

Please apply the following patches for rc2 so that the localization can be applied on a cleaned up pot file.

Re: [PATCH 2/2] apply: handle assertion failure gracefully

ndex cbf7cc7f2..9219d2737 100644 >>>>> --- a/apply.c >>>>> +++ b/apply.c >>>>> @@ -3652,7 +3652,6 @@ static int check_preimage(struct apply_state *state, >>>>> if (!old_name) >>>>> return 0; >>>&

Re: [PATCH 2/2] apply: handle assertion failure gracefully

>> +++ b/apply.c >>>> @@ -3652,7 +3652,6 @@ static int check_preimage(struct apply_state *state, >>>>if (!old_name) >>>>return 0; >>>> >>>> - assert(patch->is_new <= 0); >>> >>> 5c47f4c6 (builtin

Re: [PATCH 2/2] apply: handle assertion failure gracefully

d_name) return 0; - assert(patch->is_new <= 0); 5c47f4c6 (builtin-apply: accept patch to an empty file) added that line. Its intent was to handle diffs that contain an old name even for a file that's created. Citing from its commit message: "When we cannot be sure by

Re: [PATCH 1/2] apply: guard against renames of non-existant empty files

Am 27.02.2017 um 21:10 schrieb Junio C Hamano: René Scharfe writes: Would it make sense to mirror the previously existing condition and check for is_new instead? I.e.: if ((!patch->is_delete && !patch->new_name) ||

Re: [PATCH 1/2] apply: guard against renames of non-existant empty files

René Scharfe writes: > Would it make sense to mirror the previously existing condition and > check for is_new instead? I.e.: > > if ((!patch->is_delete && !patch->new_name) || > (!patch->is_new&& !patch->old_name)) { > Yes,

Re: [PATCH 2/2] apply: handle assertion failure gracefully

; return 0; >> >> -assert(patch->is_new <= 0); > > 5c47f4c6 (builtin-apply: accept patch to an empty file) added that > line. Its intent was to handle diffs that contain an old name even for > a file that's created. Citing from its commit message: "

Re: [PATCH 2/2] apply: handle assertion failure gracefully

Am 25.02.2017 um 11:13 schrieb Vegard Nossum: For the patches in the added testcases, we were crashing with: git-apply: apply.c:3665: check_preimage: Assertion `patch->is_new <= 0' failed. As it turns out, check_preimage() is prepared to handle these conditions, so we can

Re: [PATCH 1/2] apply: guard against renames of non-existant empty files

t/t4154-apply-git-header.sh | 15 +++ 2 files changed, 17 insertions(+), 1 deletion(-) create mode 100755 t/t4154-apply-git-header.sh diff --git a/apply.c b/apply.c index 0e2caeab9..cbf7cc7f2 100644 --- a/apply.c +++ b/apply.c @@ -1585,7 +1585,8 @@ static int find_header(struct apply_sta

Re: [PATCH 1/2] apply: guard against renames of non-existant empty files

From: "Vegard Nossum" On 25/02/2017 12:59, Philip Oakley wrote: From: "Vegard Nossum" If we have a patch like the one in the new test-case, then we will "the one in the new test-case" needs a clearer reference to the particular case so

Re: [PATCH 1/2] apply: guard against renames of non-existant empty files

On 25/02/2017 12:59, Philip Oakley wrote: From: "Vegard Nossum" If we have a patch like the one in the new test-case, then we will "the one in the new test-case" needs a clearer reference to the particular case so that future readers will know what it refers to.

Re: [PATCH 1/2] apply: guard against renames of non-existant empty files

<vegard.nos...@oracle.com> --- apply.c | 3 ++- t/t4154-apply-git-header.sh | 15 +++ 2 files changed, 17 insertions(+), 1 deletion(-) create mode 100755 t/t4154-apply-git-header.sh diff --git a/apply.c b/apply.c index 0e2caeab9..cbf7cc7f2 100644 --- a/apply.c +++ b/apply.c @@ -15

[PATCH 1/2] apply: guard against renames of non-existant empty files

nce). The patch file is completely bogus as it tries to rename something that is known not to exist, so we can throw an error for this. Found using AFL. Signed-off-by: Vegard Nossum <vegard.nos...@oracle.com> --- apply.c | 3 ++- t/t4154-apply-git-header.sh | 15 +++

[PATCH 2/2] apply: handle assertion failure gracefully

For the patches in the added testcases, we were crashing with: git-apply: apply.c:3665: check_preimage: Assertion `patch->is_new <= 0' failed. As it turns out, check_preimage() is prepared to handle these conditions, so we can remove the assertion. Found using AFL. Signed-off-by:

Re: [BUG] submodule config does not apply to upper case submodules?

On Wed, Feb 15, 2017 at 03:37:37PM -0800, Junio C Hamano wrote: > Stefan Beller writes: > > > Yes; though I'd place it in strbuf.{c,h} as it is operating > > on the internals of the strbuf. (Do we make any promises outside of > > strbuf about the internals? I mean we use

Re: [BUG] submodule config does not apply to upper case submodules?

Jonathan Tan writes: > On 02/15/2017 03:11 PM, Junio C Hamano wrote: >> Junio C Hamano writes: >> >> Perhaps something like this? > > This looks good. I was hoping to unify the processing logic between > this CLI parsing and the usual stream parsing,

Re: [BUG] submodule config does not apply to upper case submodules?

Ahh, that would work, too. On Wed, Feb 15, 2017 at 3:43 PM, Stefan Beller wrote: > On Wed, Feb 15, 2017 at 3:37 PM, Junio C Hamano wrote: >> Stefan Beller writes: >> >>> Yes; though I'd place it in strbuf.{c,h} as it is operating >>>

Re: [BUG] submodule config does not apply to upper case submodules?

On Wed, Feb 15, 2017 at 3:37 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> Yes; though I'd place it in strbuf.{c,h} as it is operating >> on the internals of the strbuf. (Do we make any promises outside of >> strbuf about the internals? I mean we

Re: [BUG] submodule config does not apply to upper case submodules?

Stefan Beller writes: > Yes; though I'd place it in strbuf.{c,h} as it is operating > on the internals of the strbuf. (Do we make any promises outside of > strbuf about the internals? I mean we use .buf all the time, so maybe > I am overly cautious here) I'd rather have it

Re: [BUG] submodule config does not apply to upper case submodules?

On 02/15/2017 03:11 PM, Junio C Hamano wrote: Junio C Hamano writes: Perhaps something like this? This looks good. I was hoping to unify the processing logic between this CLI parsing and the usual stream parsing, but this approach is probably simpler. config.c | 16

Re: [BUG] submodule config does not apply to upper case submodules?

On Wed, Feb 15, 2017 at 3:11 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Jonathan Tan writes: >> >>> I had some time to look into this, and yes, command-line parameters >>> are too aggressively downcased

Re: [BUG] submodule config does not apply to upper case submodules?

Junio C Hamano writes: > Jonathan Tan writes: > >> I had some time to look into this, and yes, command-line parameters >> are too aggressively downcased ("git_config_parse_parameter" calls >> "strbuf_tolower" on the entire key part in config.c). > >

Re: [BUG] submodule config does not apply to upper case submodules?

Jonathan Tan writes: > I had some time to look into this, and yes, command-line parameters > are too aggressively downcased ("git_config_parse_parameter" calls > "strbuf_tolower" on the entire key part in config.c). Ahh, thanks. So this is not about submodules at all;

Re: [BUG] submodule config does not apply to upper case submodules?

On 02/15/2017 10:53 AM, Junio C Hamano wrote: Lars Schneider writes: It looks like as if submodule configs ("submodule.*") for submodules with upper case names are ignored. This observation is surprising, as the second level in three-level names like ".." is

Re: [BUG] submodule config does not apply to upper case submodules?

Lars Schneider writes: > It looks like as if submodule configs ("submodule.*") for submodules > with upper case names are ignored. This observation is surprising, as the second level in three-level names like ".." is designed to be case sensitive. A code that uses the

Re: [BUG] submodule config does not apply to upper case submodules?

f9f > Checkout:git fetch https://github.com/larsxschneider/git > submodule/uppercase-bug-v1 && git checkout a122feaf9f I like these notes, though base commit is duplicate with below. > +test_expect_success 'submodule config does not apply to upper case > submodules' ' .

[BUG] submodule config does not apply to upper case submodules?

test_cmp expect actual ' +test_expect_success 'submodule config does not apply to upper case submodules' ' + test_when_finished "rm -rf super lowersub clone-success clone-failure" && + mkdir lowersub && + ( + cd lowersub && +

[PATCH 2/5] apply: use SWAP macro

Use the exported macro SWAP instead of the file-scoped macro swap and remove the latter's definition. Signed-off-by: Rene Scharfe --- apply.c | 23 +++ 1 file changed, 7 insertions(+), 16 deletions(-) diff --git a/apply.c b/apply.c index 2ed808d429..0e2caeab9c

Re: interaction between git-diff-index and git-apply

Ariel Davis <ariel.z.da...@icloud.com> writes: > I have noticed an interesting interaction between git-diff-index and > git-apply. > Essentially, it seems that if we start with a clean working tree, then > git-apply a patch, then git-apply the reverse of that patch, git-diff-in

interaction between git-diff-index and git-apply

Hello, I have noticed an interesting interaction between git-diff-index and git-apply. Essentially, it seems that if we start with a clean working tree, then git-apply a patch, then git-apply the reverse of that patch, git-diff-index still thinks files are modified. But then, if we git-status

Re: git-apply: warn/fail on *changed* end of line (eol) *only*?

On 27/12/2016 18:27, Junio C Hamano wrote: > To see the problem with "check existing lines", it probably is > easier to extend the above example to start from a file with one > more line, like this: > > 1 > 3 > 4 > 5 > > and extend all the example patches to remove "4 " line

Re: git-apply: warn/fail on *changed* end of line (eol) *only*?

Junio C Hamano writes: > Imagine that the project wants LF line endings, i.e. it considers > that a line with CRLF ending has an unwanted "whitespace" at the > end. Now, you start from this source file: > > 1 > 3 > 5 > > and a patch like this comes in: > >

Re: git-apply: warn/fail on *changed* end of line (eol) *only*?

ous hunk (or the whole file, even) has "incorrect" line endings (, as far as Git is concerned, as in the given example), it seems more sensible to me for Git to warn you about _that_ first, rather than keep silent and apply a new hunk introducing line endings without you even knowing -

Re: git-apply: warn/fail on *changed* end of line (eol) *only*?

Igor Djordjevic BugA <igor.d.djordje...@gmail.com> writes: > In short -- git-apply warns on applying the patch with CRLF line endings > (new), considered whitespace errors, even when previous hunk version > (old) has/had that very same CRLF line endings, too, so nothing act

Re: git-apply: warn/fail on *changed* end of line (eol) *only*?

On 26/12/2016 00:49, Igor Djordjevic BugA wrote: > This is a follow-up of a message posted at git-users Google group[1], > as the topic may actually be better suited for this mailing list > instead. If needed, some elaboration on the context can be found there, > as well as a detailed example

git-apply: warn/fail on *changed* end of line (eol) *only*?

(or directly here[2], second half of the message). In short -- git-apply warns on applying the patch with CRLF line endings (new), considered whitespace errors, even when previous hunk version (old) has/had that very same CRLF line endings, too, so nothing actually changed in this regards. Even worse

Re: trustExitCode doesn't apply to vimdiff mergetool

David Aguilar writes: > deltawalker, diffmerge, emerge, kdiff3, kompare, and tkdiff originally > provided behavior that matched trustExitCode=true. > > The default for all tools is trustExitCode=false, which conflicts with > these tools' defaults. Allow tools to advertise

Re: trustExitCode doesn't apply to vimdiff mergetool

On Sun, Nov 27, 2016 at 05:45:38PM -0800, David Aguilar wrote: > On Sun, Nov 27, 2016 at 11:55:59AM -0500, Jeff King wrote: > > On Sun, Nov 27, 2016 at 08:46:40AM -0500, Dun Peal wrote: > > > > > Ignoring a non-zero exit code from the merge tool, and assuming a > > > successful merge in that

Re: trustExitCode doesn't apply to vimdiff mergetool

On Sun, Nov 27, 2016 at 05:45:38PM -0800, David Aguilar wrote: > I have a patch that makes it so that none of the tools do the > check_unchanged logic themselves and instead rely on the > library code to handle it for them. This makes the > implementation uniform across all tools, and allows

Re: trustExitCode doesn't apply to vimdiff mergetool

On Sun, Nov 27, 2016 at 11:55:59AM -0500, Jeff King wrote: > On Sun, Nov 27, 2016 at 08:46:40AM -0500, Dun Peal wrote: > > > Ignoring a non-zero exit code from the merge tool, and assuming a > > successful merge in that case, seems like the wrong default behavior > > to me. > > Yeah, I'm

Re: trustExitCode doesn't apply to vimdiff mergetool

On Sun, Nov 27, 2016 at 08:46:40AM -0500, Dun Peal wrote: > Ignoring a non-zero exit code from the merge tool, and assuming a > successful merge in that case, seems like the wrong default behavior > to me. Yeah, I'm inclined to agree. But like I said, I'm not too familiar with this area, so

Re: trustExitCode doesn't apply to vimdiff mergetool

Thanks, Jeff. Ignoring a non-zero exit code from the merge tool, and assuming a successful merge in that case, seems like the wrong default behavior to me. If your merge tool quit with an error, it is more sensible to assume that the resolution you were working on has not been successfully

Re: trustExitCode doesn't apply to vimdiff mergetool

On Sat, Nov 26, 2016 at 09:44:36PM -0500, Dun Peal wrote: > I'm using vimdiff as my mergetool, and have the following lines in > ~/.gitconfig: > > [merge] > tool = vimdiff > [mergetool "vimdiff"] > trustExitCode = true > > > My understanding from the docs is that this sets >

trustExitCode doesn't apply to vimdiff mergetool

I'm using vimdiff as my mergetool, and have the following lines in ~/.gitconfig: [merge] tool = vimdiff [mergetool "vimdiff"] trustExitCode = true My understanding from the docs is that this sets mergetool.vimdiff.trustExitCode to true, thereby concluding that a merge hasn't been

Re: `git stash apply` deleted a random dir from my working copy

to ask "how do I restore it?", as well. > > On Thu, Nov 3, 2016 at 6:06 PM, Stefan Monov <logix...@gmail.com> wrote: >> Hi. >> >> I just tried `git stash save` for the first time. It worked fine. Then >> I tried `git stash apply` and while my uncommitt

Re: `git stash apply` deleted a random dir from my working copy

te: > Hi. > > I just tried `git stash save` for the first time. It worked fine. Then > I tried `git stash apply` and while my uncommitted changes were > restored, another effect was that a random dir from the root of my > working copy was deleted. I don't know why it chose that

`git stash apply` deleted a random dir from my working copy

Hi. I just tried `git stash save` for the first time. It worked fine. Then I tried `git stash apply` and while my uncommitted changes were restored, another effect was that a random dir from the root of my working copy was deleted. I don't know why it chose that exact dir, there's lots of other

Re: Stash pop/apply conflict and --theirs and --ours

On Sun, Oct 23, 2016 at 12:58:12AM +0200, Sven Strickroth wrote: > I regularly experience that beginners have problems unterstanding that > --ours and --theirs are swapped when a conflict occurrs on git stash > apply or stash pop. > > From the HCI perspective this is really counte

Stash pop/apply conflict and --theirs and --ours

Hi, I regularly experience that beginners have problems unterstanding that --ours and --theirs are swapped when a conflict occurrs on git stash apply or stash pop. >From the HCI perspective this is really counter intuitive. So, I'd like to propose that on git shash pop/apply theirs and o

[PATCH 1/4] i18n: apply: mark error message for translation

ne %d)"), state->linenr); return -128; } patch->is_toplevel_relative = 1; diff --git a/t/t4254-am-corrupt.sh b/t/t4254-am-corrupt.sh index 9bd7dd2..168739c 100755 --- a/t/t4254-am-corrupt.sh +++ b/t/t4254-am-cor

Re: [PATCH 1/3] i18n: apply: mark plural string for translation

Vasco Almeida writes: > Mark plural string for translation using Q_(). > > Signed-off-by: Vasco Almeida > --- Thanks for waiting (patiently) for 'master' to become ready to take these three patches.

[PATCH 2/3] i18n: apply: mark info messages for translation

Mark messages for translation printed to stderr. Signed-off-by: Vasco Almeida --- apply.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/apply.c b/apply.c index 201d3a7..13b2064 100644 --- a/apply.c +++ b/apply.c @@ -3554,7 +3554,7 @@ static

[PATCH 1/3] i18n: apply: mark plural string for translation

@@ int apply_all_patches(struct apply_state *state, goto end; } if (state->applied_after_fixing_ws && state->apply) - warning("%d line%s applied after" -

[PATCH 3/3] i18n: apply: mark error messages for translation

t apply_state *state, /* Binary patch is irreversible without the optional second hunk */ if (state->apply_in_reverse) { if (!fragment->next) - return error("cannot reverse-apply a binary patch " -

[PATCH v3 01/14] i18n: apply: mark plural string for translation

+++ b/builtin/apply.c @@ -4768,10 +4768,12 @@ static int apply_all_patches(struct apply_state *state, state->whitespace_error), state->whitespace_error); if (state->applied_after_fixing_ws

[PATCH v3 03/14] i18n: apply: mark info messages for translation

Mark messages for translation printed to stderr. Signed-off-by: Vasco Almeida --- builtin/apply.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/builtin/apply.c b/builtin/apply.c index ef2c084..43ab7c5 100644 --- a/builtin/apply.c +++

[PATCH v3 02/14] i18n: apply: mark error messages for translation

n_reverse) { if (!fragment->next) - return error("cannot reverse-apply a binary patch " -"without the reverse hunk to '%s'", + return error(_("cannot reverse-apply a binary patch " +

[PATCH v2 01/14] i18n: apply: mark plural string for translation

+++ b/builtin/apply.c @@ -4768,10 +4768,12 @@ static int apply_all_patches(struct apply_state *state, state->whitespace_error), state->whitespace_error); if (state->applied_after_fixing_ws

[PATCH v2 02/14] i18n: apply: mark error messages for translation

n_reverse) { if (!fragment->next) - return error("cannot reverse-apply a binary patch " -"without the reverse hunk to '%s'", + return error(_("cannot reverse-apply a binary patch " +

[PATCH v2 03/14] i18n: apply: mark info messages for translation

Mark messages for translation printed to stderr. Signed-off-by: Vasco Almeida --- builtin/apply.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/builtin/apply.c b/builtin/apply.c index ef2c084..43ab7c5 100644 --- a/builtin/apply.c +++

Re: [PATCH 01/13] i18n: apply: mark plural string for translation

Thanks. I'll skip 01-03/13 and queue the remainder for now, as I'd want to see Christian's "split builtin/apply.c into two, moving bulk to apply.c at the top-level to be reused" merged to 'next' sooner and to 'master' hopefully during this cycle.

Re: [PATCH v14 00/41] libify apply and use lib in am, part 2

1 were in v10, v12 and v13. > > They implement a way to make the libified apply code silent by > changing the bool `apply_verbosely` into a tristate enum called > `apply_verbosity`, that can be one of `verbosity_verbose`, > `verbosity_normal` or `verbosity_silent`. This is a reasona

[PATCH 03/13] i18n: apply: mark info messages for translation

Mark messages for translation printed to stderr. Signed-off-by: Vasco Almeida --- builtin/apply.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/builtin/apply.c b/builtin/apply.c index ef2c084..43ab7c5 100644 --- a/builtin/apply.c +++

[PATCH 01/13] i18n: apply: mark plural string for translation

+++ b/builtin/apply.c @@ -4768,10 +4768,12 @@ static int apply_all_patches(struct apply_state *state, state->whitespace_error), state->whitespace_error); if (state->applied_after_fixing_ws

[PATCH 02/13] i18n: apply: mark error messages for translation

n_reverse) { if (!fragment->next) - return error("cannot reverse-apply a binary patch " -"without the reverse hunk to '%s'", + return error(_("cannot reverse-apply a binary patch " +

Re: [PATCH v14 00/41] libify apply and use lib in am, part 2

On Sun, Sep 4, 2016 at 1:17 PM, Christian Couder <christian.cou...@gmail.com> wrote: > Goal > > > This is a patch series about libifying `git apply` functionality, and > using this libified functionality in `git am`, so that no 'git apply' > process is spawn any

Re: [PATCH v14 30/41] Move libified code from builtin/apply.c to apply.{c,h}

On Sun, Sep 4, 2016 at 1:18 PM, Christian Couder <christian.cou...@gmail.com> wrote: > As most of the apply code in builtin/apply.c has been libified by a number of > previous commits, it can now be moved to apply.{c,h}, so that more code can > use it. > > Helped-by: Nguyễ

[PATCH v2 02/20] builtin/apply: convert static functions to struct object_id

strlen(patch->new_sha1_prefix) != GIT_SHA1_HEXSZ || + get_oid_hex(patch->old_sha1_prefix, ) || + get_oid_hex(patch->new_sha1_prefix, )) return error("cannot apply binary patch to '%s' " "without full index line"

[PATCH v14 41/41] builtin/am: use apply API in run_apply()

This replaces run_apply() implementation with a new one that uses the apply API that has been previously prepared in apply.c and apply.h. This shoud improve performance a lot in certain cases. As the previous implementation was creating a new `git apply` process to apply each patch, it could

[PATCH v14 07/41] builtin/apply: make parse_single_patch() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in builtin/apply.c, parse_single_patch() should return a negative integer instead of calling die(). Let's do that by using error

[PATCH v14 21/41] builtin/apply: make add_conflicted_stages_file() return -1 on error

To libify `git apply` functionality we have to signal errors to the caller instead of die()ing. To do that in a compatible manner with the rest of the error handling in "builtin/apply.c", add_conflicted_stages_file() should return -1 instead of calling die(). Helped-by: Eric Sunsh

[PATCH v14 33/41] apply: make it possible to silently apply

is 'verbosity_silent'. It should prevent anything to be printed on both stderr and stdout. This is needed because `git am` wants to first call apply functionality silently, if it can then fall back on 3-way merge in case of error. Printing on stdout, and calls to warning() or error() are not taken care

[PATCH v14 34/41] apply: don't print on stdout in verbosity_silent mode

When apply_verbosity is set to verbosity_silent nothing should be printed on both stderr and stdout. To avoid printing on stdout, we can just skip calling the following functions: - stat_patch_list(), - numstat_patch_list(), - summary_patch_list(). It is safe to do that

<    1   2   3   4   5   6   7   8   9   10   >