Re: [PATCH 4/5] t4108: demonstrate bug in apply

2019-10-23 Thread Eric Sunshine
On Wed, Oct 23, 2019 at 8:04 AM Denton Liu wrote: > Currently, apply does not respect the merge.conflictStyle setting. > Demonstrate this by making the 'apply with --3way' test case generic and > extending it to show that the configuration of > merge.conflictStyle = d

[PATCH 0/5] apply: fix merge.conflictStyle bug in --3way

2019-10-23 Thread Denton Liu
This fixes a bug where even if `merge.conflictStyle = diff3`, running `git apply --3way` would not output the base. Patches 1-3 are general cleanup for t4108, 4 demonstrates the bug and 5 actually fixes it. Denton Liu (5): t4108: replace create_file with test_write_lines t4108: remove git

[PATCH 4/5] t4108: demonstrate bug in apply

2019-10-23 Thread Denton Liu
Currently, apply does not respect the merge.conflictStyle setting. Demonstrate this by making the 'apply with --3way' test case generic and extending it to show that the configuration of merge.conflictStyle = diff3 causes a breakage. Change print_sanitized_diff() to als

[PATCH 5/5] apply: respect merge.conflictStyle in --3way

2019-10-23 Thread Denton Liu
d-off-by: Denton Liu --- apply.c | 2 +- t/t4108-apply-threeway.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/apply.c b/apply.c index f8a046a6a5..b9291f5f7b 100644 --- a/apply.c +++ b/apply.c @@ -32,7 +32,7 @@ static void git_apply_config(void) { git_con

Re: [PATCH] apply: tell user location of corrupted patch file

2019-10-05 Thread Junio C Hamano
%s:%d"), >> state->patch_input_file, state->linenr); >> } > > Do not forget that you can run "git apply" and feed the patch from > its standard input, e.g. > > $ git apply$ git show -R | git apply > > Make sure state-&g

Re: [PATCH] apply: tell user location of corrupted patch file

2019-10-05 Thread Junio C Hamano
Junio C Hamano writes: >> An alternate design was considered which involved printing the line >> numbers relative to the output of `git am --show-current-patch` (in >> other words, the actual mail file that's provided to am). This design >> was not chosen because am does not store the whole mail

Re: [PATCH] apply: tell user location of corrupted patch file

2019-10-05 Thread Junio C Hamano
. This assumption, however, > is incorrect. The line count really refers to the > .git/rebase-apply/patch file genrated by am. > > Teach am to print the location of corrupted patch files so that users of s/corrupted/corrupt/; > the tool will know where to look when fixing their corr

[PATCH] apply: tell user location of corrupted patch file

2019-10-04 Thread Denton Liu
count really refers to the .git/rebase-apply/patch file genrated by am. Teach am to print the location of corrupted patch files so that users of the tool will know where to look when fixing their corrupted patch. Thus the error message will look like this: error: corrupt patch at .git/rebase-

[PATCH v2 1/1] stash apply: report status correctly even in a worktree's subdirectory

2019-10-04 Thread Johannes Schindelin via GitGitGadget
directory of the work tree, and neither is it inside the parent directory of `GIT_DIR`. This fixes the problem where `git stash apply` would report pretty much everything deleted or untracked when run inside a worktree's subdirectory. To make sure that we do not introduce the "reverse

[PATCH v2 0/1] stash apply: be prepared to run in a worktree's subdirectory

2019-10-04 Thread Johannes Schindelin via GitGitGadget
do stash quite often (now that git stash's performance is a joy on Windows). Changes since v1: * We now make sure to also set GIT_DIR. Johannes Schindelin (1): stash apply: report status correctly even in a worktree's subdirectory builtin/stash.c | 4 t/t390

Re: [PATCH 1/1] stash apply: report status correctly even in a worktree's subdirectory

2019-10-04 Thread Johannes Schindelin
ee.sh > > @@ -0,0 +1,27 @@ > > +#!/bin/sh > > +# > > +# Copyright (c) 2019 Johannes E Schindelin > > +# > > + > > +test_description='Test git stash in a worktree' > > + > > +. ./test-lib.sh > > + > > +test_expec

Re: [PATCH 1/1] stash apply: report status correctly even in a worktree's subdirectory

2019-10-03 Thread Junio C Hamano
b.sh > + > +test_expect_success 'setup' ' > + test_commit initial && > + git worktree add wt && > + test_commit -C wt in-worktree > +' > + > +test_expect_success 'apply in subdirectory' ' > + mkdir wt/subd

[PATCH 1/1] stash apply: report status correctly even in a worktree's subdirectory

2019-09-25 Thread Johannes Schindelin via GitGitGadget
tree, and neither is it inside the parent directory of `GIT_DIR`. This fixes the problem where `git stash apply` would report pretty much everything deleted or untracked when run inside a worktree's subdirectory. Signed-off-by: Johannes Schindelin --- builtin/stash.c | 2 ++ t

[PATCH 0/1] stash apply: be prepared to run in a worktree's subdirectory

2019-09-25 Thread Johannes Schindelin via GitGitGadget
do stash quite often (now that git stash's performance is a joy on Windows). Johannes Schindelin (1): stash apply: report status correctly even in a worktree's subdirectory builtin/stash.c | 2 ++ t/t3908-stash-in-worktree.sh | 27 +++ 2 files c

Re: error: could not read '.git/rebase-apply/head-name': No such file or directory

2019-09-12 Thread Johannes Schindelin
Hi Eugen, On Thu, 12 Sep 2019, Eugen Konkov wrote: > $ git --version > git version 2.20.1 First thing to try is whether Git v2.23.0 still exposes that bug. Ciao, Johannes

error: could not read '.git/rebase-apply/head-name': No such file or directory

2019-09-12 Thread Eugen Konkov
Hello Git, Next commands cause the error: $ git pull fatal: It seems that there is already a rebase-apply directory, and I wonder if you are in the middle of another rebase. If that is the case, please try git rebase (--continue | --abort | --skip) If that is not the case, please

Re: [PATCH 1/2] mingw: apply array.cocci rule

2019-09-04 Thread Junio C Hamano
Johannes Schindelin writes: > Hi Denton, > > On Wed, 4 Sep 2019, Denton Liu wrote: > >> After running Coccinelle on all sources inside compat/ that were created >> by us[1], it was found that compat/mingw.c violated an array.cocci rule >> in two places and, thus

Re: [PATCH 1/2] mingw: apply array.cocci rule

2019-09-04 Thread Johannes Schindelin
Hi Denton, On Wed, 4 Sep 2019, Denton Liu wrote: > After running Coccinelle on all sources inside compat/ that were created > by us[1], it was found that compat/mingw.c violated an array.cocci rule > in two places and, thus, a patch was generated. Apply this patch so that > all com

[PATCH 1/2] mingw: apply array.cocci rule

2019-09-04 Thread Denton Liu
After running Coccinelle on all sources inside compat/ that were created by us[1], it was found that compat/mingw.c violated an array.cocci rule in two places and, thus, a patch was generated. Apply this patch so that all compat/ sources created by us follows all cocci rules. [1]: Do not run

[PATCH v3 3/4] git-gui: return early when patch fails to apply

2019-08-28 Thread Pratyush Yadav
In the procedure apply_or_revert_range_or_line, if the patch does not apply successfully, a dialog is shown, but execution proceeds after that. Instead, return early on error so the parts that come after this don't work on top of an error state. Signed-off-by: Pratyush Yadav --- lib/dif

Re: [PATCH v4 2/2] apply: reload .gitattributes after patching it

2019-08-26 Thread Junio C Hamano
Phillip Wood writes: > I spent some time digging into this and the attributes are reloaded > before each pick. This is because check_updates() called by > unpack_trees() calls git_attr_set_direction(GIT_ATTR_CHECKOUT) at the > start of the function and git_attr_set_direction(GIT_ATTR_CHECKIN) at

Re: [PATCH v4 2/2] apply: reload .gitattributes after patching it

2019-08-26 Thread Phillip Wood
On 20/08/2019 19:32, Phillip Wood wrote: On 20/08/2019 19:24, Junio C Hamano wrote: Phillip Wood writes: Do you know why -m and -i aren't affected? I had to look, but I believe the answer is because they use the sequencer, and the sequencer calls git merge-recursive as a separate process, a

Re: [BUG] builtin "stash apply" does not refresh index

2019-08-23 Thread Junio C Hamano
Jeff King writes: > This started with 8a0fc8d19d (stash: convert apply to builtin, > 2019-02-25), which is in v2.22.0. Interestingly, do_stash_apply() does > in fact call refresh_cache(). But it looks like we don't ever write it > out to disk. So when we later call merg

[BUG] builtin "stash apply" does not refresh index

2019-08-22 Thread Jeff King
ep 1; touch file" would work. cp file other mv other file # now try to apply the stash git stash apply The final command gives me: error: Your local changes to the following files would be overwritten by merge: file Please commit your changes or stash them before you m

Re: [PATCH v4 2/2] apply: reload .gitattributes after patching it

2019-08-20 Thread Phillip Wood
On 20/08/2019 19:24, Junio C Hamano wrote: Phillip Wood writes: Do you know why -m and -i aren't affected? I had to look, but I believe the answer is because they use the sequencer, and the sequencer calls git merge-recursive as a separate process, and so the writing of the tree is only done

Re: [PATCH v4 2/2] apply: reload .gitattributes after patching it

2019-08-20 Thread Junio C Hamano
Phillip Wood writes: >>> Do you know why -m and -i aren't affected? >> >> I had to look, but I believe the answer is because they use the >> sequencer, and the sequencer calls git merge-recursive as a separate >> process, and so the writing of the tree is only done in a subprocess, >> which can't

Re: [PATCH v4 2/2] apply: reload .gitattributes after patching it

2019-08-20 Thread Phillip Wood
On 20/08/2019 04:05, brian m. carlson wrote: On 2019-08-19 at 09:55:27, Phillip Wood wrote: On 19/08/2019 10:41, Phillip Wood wrote: [...] diff --git a/convert.c b/convert.c index 94ff837649..030e9b81b9 100644 --- a/convert.c +++ b/convert.c @@ -1293,10 +1293,11 @@ struct conv_attrs {   c

Re: [PATCH v4 2/2] apply: reload .gitattributes after patching it

2019-08-20 Thread Phillip Wood
Hi Brian On 20/08/2019 03:45, brian m. carlson wrote: On 2019-08-19 at 09:41:42, Phillip Wood wrote: Hi Brian On 18/08/2019 19:44, brian m. carlson wrote: When applying multiple patches with git am, or when rebasing using the am backend, it's possible that one of our patches has updated a git

Re: [PATCH v4 2/2] apply: reload .gitattributes after patching it

2019-08-19 Thread brian m. carlson
On 2019-08-19 at 09:55:27, Phillip Wood wrote: > On 19/08/2019 10:41, Phillip Wood wrote: > > [...] > > > diff --git a/convert.c b/convert.c > > > index 94ff837649..030e9b81b9 100644 > > > --- a/convert.c > > > +++ b/convert.c > > > @@ -1293,10 +1293,11 @@ struct conv_attrs { > > >   const char

Re: [PATCH v4 2/2] apply: reload .gitattributes after patching it

2019-08-19 Thread brian m. carlson
On 2019-08-19 at 09:41:42, Phillip Wood wrote: > Hi Brian > > On 18/08/2019 19:44, brian m. carlson wrote: > > When applying multiple patches with git am, or when rebasing using the > > am backend, it's possible that one of our patches has updated a > > gitattributes file. Currently, we cache this

Re: [PATCH v4 2/2] apply: reload .gitattributes after patching it

2019-08-19 Thread Phillip Wood
On 19/08/2019 10:41, Phillip Wood wrote: [...] diff --git a/convert.c b/convert.c index 94ff837649..030e9b81b9 100644 --- a/convert.c +++ b/convert.c @@ -1293,10 +1293,11 @@ struct conv_attrs {   const char *working_tree_encoding; /* Supported encoding or default encoding if NULL */   }; +

Re: [PATCH v4 2/2] apply: reload .gitattributes after patching it

2019-08-19 Thread Phillip Wood
Hi Brian On 18/08/2019 19:44, brian m. carlson wrote: When applying multiple patches with git am, or when rebasing using the am backend, it's possible that one of our patches has updated a gitattributes file. Currently, we cache this information, so if a file in a subsequent patch has attributes

[PATCH v4 2/2] apply: reload .gitattributes after patching it

2019-08-18 Thread brian m. carlson
When applying multiple patches with git am, or when rebasing using the am backend, it's possible that one of our patches has updated a gitattributes file. Currently, we cache this information, so if a file in a subsequent patch has attributes applied, the file will be written out with the attribute

Re: [PATCH v3 2/2] apply: reload .gitattributes after patching it

2019-08-15 Thread brian m. carlson
On 2019-08-15 at 22:10:29, Junio C Hamano wrote: > Junio C Hamano writes: > > > "brian m. carlson" writes: > > > >> When applying multiple patches with git am, or when rebasing using the > >> am backend, it's possible that one of our patches has updated a > >> gitattributes file. Currently, we c

Re: [PATCH v3 2/2] apply: reload .gitattributes after patching it

2019-08-15 Thread Junio C Hamano
Junio C Hamano writes: > "brian m. carlson" writes: > >> When applying multiple patches with git am, or when rebasing using the >> am backend, it's possible that one of our patches has updated a >> gitattributes file. Currently, we cache this information, so if a >> file in a subsequent patch ha

Re: [PATCH v3 2/2] apply: reload .gitattributes after patching it

2019-08-13 Thread brian m. carlson
On 2019-08-13 at 22:37:56, Junio C Hamano wrote: > "brian m. carlson" writes: > > > +test_expect_success 'rebase --am and .gitattributes' ' > > + test_create_repo attributes && > > + ( > > + cd attributes && > > + test_commit init && > > + test_config filter.test

Re: [PATCH v3 2/2] apply: reload .gitattributes after patching it

2019-08-13 Thread Junio C Hamano
"brian m. carlson" writes: > +test_expect_success 'rebase --am and .gitattributes' ' > + test_create_repo attributes && > + ( > + cd attributes && > + test_commit init && > + test_config filter.test.clean "sed -e > '\''s/smudged/clean/g'\''" && > +

Re: [PATCH v3 2/2] apply: reload .gitattributes after patching it

2019-08-13 Thread Junio C Hamano
ttributes applied, the file will be > written out with the attributes in place as of the time we started the > rebase or am operation, not with the attributes applied by the previous > patch. This problem does not occur when using the -m or -i flags to > rebase. Back when "am"

[PATCH v3 2/2] apply: reload .gitattributes after patching it

2019-08-13 Thread brian m. carlson
When applying multiple patches with git am, or when rebasing using the am backend, it's possible that one of our patches has updated a gitattributes file. Currently, we cache this information, so if a file in a subsequent patch has attributes applied, the file will be written out with the attribute

[PATCH v2 2/2] apply: reload .gitattributes after patching it

2019-08-11 Thread brian m. carlson
When applying multiple patches with git am, or when rebasing using the am backend, it's possible that one of our patches has updated a gitattributes file. Currently, we cache this information, so if a file in a subsequent patch has attributes applied, the file will be written out with the attribute

Re: [PATCH] apply: reload .gitattributes after patching it

2019-08-09 Thread brian m. carlson
On 2019-08-09 at 13:51:49, Jeff King wrote: > On Fri, Aug 09, 2019 at 02:43:18PM +0200, SZEDER Gábor wrote: > > But there is an other subtlety here: when I read the commit message > > saying "patch that touches a path ending in ".gitattributes"." and saw > > the new call to strip_path_suffix(), I i

Re: [PATCH] apply: reload .gitattributes after patching it

2019-08-09 Thread Jeff King
On Fri, Aug 09, 2019 at 02:43:18PM +0200, SZEDER Gábor wrote: > > I think you could do this with: > > > > size_t len; > > if (strip_suffix(patch->new_name, GITATTRIBUTES_FILE, &len) && > > len > 0 && is_dir_sep(patch->new_name[len-1])) > > flush_attributes = 1; > > > > Not su

Re: [PATCH] apply: reload .gitattributes after patching it

2019-08-09 Thread SZEDER Gábor
On Fri, Aug 09, 2019 at 07:36:14AM -0400, Jeff King wrote: > On Fri, Aug 09, 2019 at 11:25:52AM +, brian m. carlson wrote: > > > > > + if (!flush_attributes && patch->new_name) { > > > > + char *dummy = > > > > strip_path_suffix(patch->new_n

Re: [PATCH] apply: reload .gitattributes after patching it

2019-08-09 Thread brian m. carlson
On 2019-08-09 at 11:36:14, Jeff King wrote: > I think you could do this with: > > size_t len; > if (strip_suffix(patch->new_name, GITATTRIBUTES_FILE, &len) && > len > 0 && is_dir_sep(patch->new_name[len-1])) > flush_attributes = 1; > > Not sure if that is better or worse. It a

Re: [PATCH] apply: reload .gitattributes after patching it

2019-08-09 Thread Jeff King
On Fri, Aug 09, 2019 at 11:25:52AM +, brian m. carlson wrote: > > > + if (!flush_attributes && patch->new_name) { > > > + char *dummy = > > > strip_path_suffix(patch->new_name, GITATTRIBUTES_FILE); > > > > It's a shame that 'strip_path_suffix' doesn't

Re: [PATCH] apply: reload .gitattributes after patching it

2019-08-09 Thread brian m. carlson
On 2019-08-09 at 11:14:52, Taylor Blau wrote: > > diff --git a/apply.c b/apply.c > > index cde95369bb..b959b88b8e 100644 > > --- a/apply.c > > +++ b/apply.c > > @@ -4643,6 +4643,7 @@ static int apply_patch(struct apply_state *state, > > struct patch *list = NULL, **listp = &list; > > int sk

Re: [PATCH] apply: reload .gitattributes after patching it

2019-08-09 Thread Taylor Blau
Hi brian, On Fri, Aug 09, 2019 at 10:02:17AM +, brian m. carlson wrote: > When applying multiple patches with git am, or when rebasing using the > am backend, it's possible that one of our patches has updated a > gitattributes file. Currently, we cache this information, so if a > file in a sub

[PATCH] apply: reload .gitattributes after patching it

2019-08-09 Thread brian m. carlson
When applying multiple patches with git am, or when rebasing using the am backend, it's possible that one of our patches has updated a gitattributes file. Currently, we cache this information, so if a file in a subsequent patch has attributes applied, the file will be written out with the attribute

Re: [PATCH] stop it from failing silently when git apply patch and show err info

2019-07-25 Thread simon gao
I create 001.patch in dir, ceph_master ceph_master |--- .git |--- src |--- tools |--- ... local project directory: storage |---.git |---ceph_**.*.** |--- src |--- tools |--- ... I'm trying to apply the patch, and git apply patch doesn't give me any errors. like this cd sto

[PATCH] stop it from failing silently when git apply patch and show err info

2019-07-25 Thread simon gao
Signed-off-by: simon gao --- apply.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/apply.c b/apply.c index 4992eca..47b16aa 100644 --- a/apply.c +++ b/apply.c @@ -2093,8 +2093,10 @@ static int use_patch(struct apply_state *state, struct patch *p) /* Paths outside

[PATCH] stop it from failing silently when git apply patch and show err info

2019-07-25 Thread simon gao
Signed-off-by: simon gao --- apply.c | 1 + 1 file changed, 1 insertion(+) diff --git a/apply.c b/apply.c index 4992eca..f66a6ff 100644 --- a/apply.c +++ b/apply.c @@ -2094,6 +2094,7 @@ static int use_patch(struct apply_state *state, struct patch *p) if (state->prefix && *state->prefix)

[PATCH v4 07/14] apply: make parse_git_diff_header public

2019-07-11 Thread Thomas Gummerer
ruct strbuf *root, + int *linenr, + int p_value, + const char *line, + int len, + unsigned int size, + struct patch *patch); + /* * Some aspects of the apply behavior are controlled by the following * bits in the "options" parameter passed to apply_all_patches(). -- 2.22.0.510.g264f2c817a

[PATCH v4 06/14] apply: only pass required data to gitdiff_* functions

2019-07-11 Thread Thomas Gummerer
name(state->root, line, NULL, state->p_value, TERM_TAB); return 0; } @@ -949,7 +955,7 @@ static int gitdiff_verify_name(struct apply_state *state, if (isnull) return error(_("git apply: bad git-diff - expected /dev/null, got %s

[PATCH v4 05/14] apply: only pass required data to find_name_*

2019-07-11 Thread Thomas Gummerer
7 @@ static int gitdiff_verify_name(struct apply_state *state, int side) { if (!*name && !isnull) { - *name = find_name(state, line, NULL, state->p_value, TERM_TAB); + *name = find_name(&state->root, line

[PATCH v4 04/14] apply: only pass required data to check_header_line

2019-07-11 Thread Thomas Gummerer
Currently the 'check_header_line()' function takes 'struct apply_state' as parameter, even though it only needs the linenr from that struct. This function is in the callchain of 'parse_git_header()', which we want to make more generally useful in a subsequent commit. To make that happen we only w

[PATCH v4 03/14] apply: only pass required data to git_header_name

2019-07-11 Thread Thomas Gummerer
Currently the 'git_header_name()' function takes 'struct apply_state' as parameter, even though it only needs the p_value from that struct. This function is in the callchain of 'parse_git_header()', which we want to make more generally useful in a subsequent commit. To make that happen we only wa

[PATCH v4 02/14] apply: only pass required data to skip_tree_prefix

2019-07-11 Thread Thomas Gummerer
Currently the 'skip_tree_prefix()' function takes 'struct apply_state' as parameter, even though it only needs the p_value from that struct. This function is in the callchain of 'parse_git_header()', which we want to make more generally useful in a subsequent commit. To make that happen we only w

[PATCH v4 01/14] apply: replace marc.info link with public-inbox

2019-07-11 Thread Thomas Gummerer
public-inbox.org links include the whole message ID by default. This means the message can still be found even if the site goes away, which is not the case with the marc.info link. Replace the marc.info link with a more future proof one. Signed-off-by: Thomas Gummerer --- apply.c | 2 +- 1 fil

Re: [PATCH v3 07/14] apply: make parse_git_header public

2019-07-10 Thread Thomas Gummerer
On 07/09, Junio C Hamano wrote: > Thomas Gummerer writes: > > > Maybe it would be even better to name it 'struct gitdiff_data', as > > it's really only used for those few functions? > > Is it really the case where "these three are only used by the > codepath you made public"? If so, I agree tha

Re: [PATCH v3 07/14] apply: make parse_git_header public

2019-07-09 Thread Junio C Hamano
Thomas Gummerer writes: > Maybe it would be even better to name it 'struct gitdiff_data', as > it's really only used for those few functions? Is it really the case where "these three are only used by the codepath you made public"? If so, I agree that "gitdiff_data" is a perfectly good name for

Re: [PATCH v3 07/14] apply: make parse_git_header public

2019-07-09 Thread Thomas Gummerer
d say 'parse_git_diff_header()' now, instead of parse_git_header of course. Will fix that in the reroll. > > Signed-off-by: Thomas Gummerer > > --- > > Thanks for these refactoring patches on "apply" machinery in the > early part of the series. I not

Re: [PATCH v3 07/14] apply: make parse_git_header public

2019-07-09 Thread Junio C Hamano
Thomas Gummerer writes: > Make parse_git_header a "public" function in apply.h, so we can re-use > it in range-diff in a subsequent commit. > > Signed-off-by: Thomas Gummerer > --- Thanks for these refactoring patches on "apply" machinery in the early part

[PATCH v3 05/14] apply: only pass required data to find_name_*

2019-07-08 Thread Thomas Gummerer
7 @@ static int gitdiff_verify_name(struct apply_state *state, int side) { if (!*name && !isnull) { - *name = find_name(state, line, NULL, state->p_value, TERM_TAB); + *name = find_name(&state->root, line

[PATCH v3 07/14] apply: make parse_git_header public

2019-07-08 Thread Thomas Gummerer
* Returns -1 on failure, the length of the parsed header otherwise. + */ +int parse_git_diff_header(struct strbuf *root, + int *linenr, + int p_value, + const char *line, + int len, +

[PATCH v3 06/14] apply: only pass required data to gitdiff_* functions

2019-07-08 Thread Thomas Gummerer
+ *name = find_name(state->root, line, NULL, state->p_value, TERM_TAB); return 0; } @@ -949,7 +955,7 @@ static int gitdiff_verify_name(struct apply_state *state, if (isnull) return error(_("gi

[PATCH v3 03/14] apply: only pass required data to git_header_name

2019-07-08 Thread Thomas Gummerer
Currently the 'git_header_name()' function takes 'struct apply_state' as parameter, even though it only needs the p_value from that struct. This function is in the callchain of 'parse_git_header()', which we want to make more generally useful in a subsequent commit. To make that happen we only wa

[PATCH v3 04/14] apply: only pass required data to check_header_line

2019-07-08 Thread Thomas Gummerer
Currently the 'check_header_line()' function takes 'struct apply_state' as parameter, even though it only needs the linenr from that struct. This function is in the callchain of 'parse_git_header()', which we want to make more generally useful in a subsequent commit. To make that happen we only w

[PATCH v3 02/14] apply: only pass required data to skip_tree_prefix

2019-07-08 Thread Thomas Gummerer
Currently the 'skip_tree_prefix()' function takes 'struct apply_state' as parameter, even though it only needs the p_value from that struct. This function is in the callchain of 'parse_git_header()', which we want to make more generally useful in a subsequent commit. To make that happen we only w

[PATCH v3 01/14] apply: replace marc.info link with public-inbox

2019-07-08 Thread Thomas Gummerer
public-inbox.org links include the whole message ID by default. This means the message can still be found even if the site goes away, which is not the case with the marc.info link. Replace the marc.info link with a more future proof one. Signed-off-by: Thomas Gummerer --- apply.c | 2 +- 1 fil

Re: [PATCH v2 06/14] apply: only pass required data to gitdiff_* functions

2019-07-05 Thread Johannes Schindelin
Hi Thomas, On Fri, 5 Jul 2019, Thomas Gummerer wrote: > Currently the 'gitdiff_*()' functions take 'struct apply_state' as > parameter, even though they only needs the root, linenr and p_value > from that struct. > > These functions are in the callchain of 'parse_git_header()', which we > want to

Re: [PATCH v2 07/14] apply: make parse_git_header public

2019-07-05 Thread Johannes Schindelin
> + int *linenr, > + int p_value, > + const char *line, > + int len, > + unsigned int size, > + struct patch *patch); > + > /* > * Some aspects of the apply be

[PATCH v2 03/14] apply: only pass required data to git_header_name

2019-07-05 Thread Thomas Gummerer
Currently the 'git_header_name()' function takes 'struct apply_state' as parameter, even though it only needs the p_value from that struct. This function is in the callchain of 'parse_git_header()', which we want to make more generally useful in a subsequent commit. To make that happen we only wa

[PATCH v2 05/14] apply: only pass required data to find_name_*

2019-07-05 Thread Thomas Gummerer
7 @@ static int gitdiff_verify_name(struct apply_state *state, int side) { if (!*name && !isnull) { - *name = find_name(state, line, NULL, state->p_value, TERM_TAB); + *name = find_name(&state->root, line

[PATCH v2 04/14] apply: only pass required data to check_header_line

2019-07-05 Thread Thomas Gummerer
Currently the 'check_header_line()' function takes 'struct apply_state' as parameter, even though it only needs the linenr from that struct. This function is in the callchain of 'parse_git_header()', which we want to make more generally useful in a subsequent commit. To make that happen we only w

[PATCH v2 01/14] apply: replace marc.info link with public-inbox

2019-07-05 Thread Thomas Gummerer
public-inbox.org links include the whole message ID by default. This means the message can still be found even if the site goes away, which is not the case with the marc.info link. Replace the marc.info link with a more future proof one. Signed-off-by: Thomas Gummerer --- apply.c | 2 +- 1 fil

[PATCH v2 02/14] apply: only pass required data to skip_tree_prefix

2019-07-05 Thread Thomas Gummerer
Currently the 'skip_tree_prefix()' function takes 'struct apply_state' as parameter, even though it only needs the p_value from that struct. This function is in the callchain of 'parse_git_header()', which we want to make more generally useful in a subsequent commit. To make that happen we only w

[PATCH v2 06/14] apply: only pass required data to gitdiff_* functions

2019-07-05 Thread Thomas Gummerer
name(state->root, line, NULL, state->p_value, TERM_TAB); return 0; } @@ -949,7 +955,7 @@ static int gitdiff_verify_name(struct apply_state *state, if (isnull) return error(_("git apply: bad git-diff - expected /dev/null, got %s

[PATCH v2 07/14] apply: make parse_git_header public

2019-07-05 Thread Thomas Gummerer
int p_value, +const char *line, +int len, +unsigned int size, +struct patch *patch); + /* * Some aspects of the apply behavior are controlled by the following * bits in the "options" parameter passed to apply_all_patches(). -- 2.22.0.510.g264f2c817a

Re: Bug Report for git apply

2019-04-11 Thread SZEDER Gábor
On Thu, Apr 11, 2019 at 03:16:22PM -0400, Can Gemicioglu wrote: > I noticed a problem when trying to apply a patch file that contained > many separate patches in a single file. To quote the first line of its manpage :) 'git apply' is meant to "Apply a patch to files and/or

Bug Report for git apply

2019-04-11 Thread Can Gemicioglu
Hi, I noticed a problem when trying to apply a patch file that contained many separate patches in a single file. Trying to apply this patch gave me a "No such file or directory" error for one of the files in the middle and after looking around I realised this file was also created

RE: regression in new built-in stash + fsmonitor (was Re: [PATCH v13 11/27] stash: convert apply to builtin)

2019-03-14 Thread Ben Peart
> It fixes not just this issue, but now the whole test suite passes with > GIT_TEST_FSMONITOR, i.e. this test that's been failing for ~2 years also > works now: > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpubli > c- > inbox.org%2Fgit%2F87k1vwn9qe.fsf%40evledraar.gmail.com%2F

Re: regression in new built-in stash + fsmonitor (was Re: [PATCH v13 11/27] stash: convert apply to builtin)

2019-03-14 Thread Ævar Arnfjörð Bjarmason
t; >> On Tue, Feb 26 2019, Thomas Gummerer wrote: >> >> >> >> > From: Joel Teichroeb >> >> > >> >> > Add a builtin helper for performing stash commands. Converting >> >> > all at once proved hard to review, so starting with just ap

Re: regression in new built-in stash + fsmonitor (was Re: [PATCH v13 11/27] stash: convert apply to builtin)

2019-03-14 Thread Johannes Schindelin
eichroeb > >> > > >> > Add a builtin helper for performing stash commands. Converting > >> > all at once proved hard to review, so starting with just apply > >> > lets conversion get started without the other commands being > >> > finished

git apply --check should give some indication that a patch applies cleanly

2019-03-14 Thread Daniel Dromboski
Hi folks, The main purpose of `git apply --check` is to see if a patch can apply. It's not intuitive to a user, just from the command name, that "no output" means your patch can apply cleanly. Furthermore, `git apply --check --verbose` only says that it is checking the pat

Re: regression in new built-in stash + fsmonitor (was Re: [PATCH v13 11/27] stash: convert apply to builtin)

2019-03-14 Thread Ævar Arnfjörð Bjarmason
h commands. Converting >> > all at once proved hard to review, so starting with just apply >> > lets conversion get started without the other commands being >> > finished. >> > >> > The helper is being implemented as a drop in replacement for &

Re: regression in new built-in stash + fsmonitor (was Re: [PATCH v13 11/27] stash: convert apply to builtin)

2019-03-14 Thread Johannes Schindelin
Hi Ævar, On Thu, 14 Mar 2019, Ævar Arnfjörð Bjarmason wrote: > On Tue, Feb 26 2019, Thomas Gummerer wrote: > > > From: Joel Teichroeb > > > > Add a builtin helper for performing stash commands. Converting > > all at once proved hard to review, so starting with

regression in new built-in stash + fsmonitor (was Re: [PATCH v13 11/27] stash: convert apply to builtin)

2019-03-14 Thread Ævar Arnfjörð Bjarmason
On Tue, Feb 26 2019, Thomas Gummerer wrote: > From: Joel Teichroeb > > Add a builtin helper for performing stash commands. Converting > all at once proved hard to review, so starting with just apply > lets conversion get started without the other commands being > finished.

[PATCH v13 11/27] stash: convert apply to builtin

2019-02-25 Thread Thomas Gummerer
From: Joel Teichroeb Add a builtin helper for performing stash commands. Converting all at once proved hard to review, so starting with just apply lets conversion get started without the other commands being finished. The helper is being implemented as a drop in replacement for stash so that

[PATCH 2/8] apply: drop unused "def" parameter from find_name_gnu()

2019-01-24 Thread Jeff King
We use the "def" parameter in find_name_common() for some heuristics, but they are not necessary with the less-ambiguous GNU format. Let's drop this unused parameter. Signed-off-by: Jeff King --- apply.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/apply.c b/apply.c i

submodule.recurse should apply to clone

2019-01-16 Thread Tim Hutt
For some reason submodule.recurse applies to everything except clone. Is there a reason for this strange inconsistency? Cheers, Tim

[PATCH v12 10/26] stash: convert apply to builtin

2018-12-20 Thread Paul-Sebastian Ungureanu
From: Joel Teichroeb Add a builtin helper for performing stash commands. Converting all at once proved hard to review, so starting with just apply lets conversion get started without the other commands being finished. The helper is being implemented as a drop in replacement for stash so that

Re: git-apply working on an index with smudged entries

2018-12-14 Thread Junio C Hamano
Christian Halstrick writes: > Question: > - is this because the index which jgit created is so corrupt that only > special commands > like "git status" can repair it? No. > - or is "git apply" not trying hard enough to consume a index with > smudg

git-apply working on an index with smudged entries

2018-12-14 Thread Christian Halstrick
I see that when I call "git apply --3way ..." on an index which was previously created by JGit and which contains smudged entries the command fails with message "error: foo.txt: does not match index". If I do a "git status" afterwards and then the same "git a

[PATCH 07/24] apply: support backup log with --keep-backup

2018-12-09 Thread Nguyễn Thái Ngọc Duy
Normally changes from git-apply are not worth logging because they come from a file and can be recovered from there. This option will mostly be used by add--interactive.pl where patches are generated during an interactive add session and are very much worth logging. The logging is a bit more

[PATCH v11 09/22] stash: convert apply to builtin

2018-11-22 Thread Paul-Sebastian Ungureanu
From: Joel Teichroeb Add a builtin helper for performing stash commands. Converting all at once proved hard to review, so starting with just apply lets conversion get started without the other commands being finished. The helper is being implemented as a drop in replacement for stash so that

Re: [PATCH 1/1] apply --recount: allow "no-op hunks"

2018-11-12 Thread Josh Steadmon
On 2018.11.12 12:54, Johannes Schindelin via GitGitGadget wrote: > From: Johannes Schindelin > > When editing patches e.g. in `git add -e`, it is quite common that a > hunk ends up having no -/+ lines, i.e. it is now supposed to do nothing. > > This use case was broken by a

[PATCH 1/1] apply --recount: allow "no-op hunks"

2018-11-12 Thread Johannes Schindelin via GitGitGadget
From: Johannes Schindelin When editing patches e.g. in `git add -e`, it is quite common that a hunk ends up having no -/+ lines, i.e. it is now supposed to do nothing. This use case was broken by ad6e8ed37bc1 (apply: reject a hunk that does not do anything, 2015-06-01) with the good intention

Re: [PATCH 01/13] apply: mark include/exclude options as NONEG

2018-11-04 Thread Junio C Hamano
Jeff King writes: > The options callback for "git apply --no-include" is not ready to handle > the "unset" parameter, and as a result will segfault when it adds a NULL > argument to the include list (likewise for "--no-exclude"). > > In theory this mi

[PATCH 11/13] apply: return -1 from option callback instead of calling exit(1)

2018-11-04 Thread Jeff King
The option callback for "apply --whitespace" exits with status "1" on error. It makes more sense for it to just return an error to parse-options. That code will exit, too, but it will use status "129" that is customary for option errors. The exit() dates back to a

[PATCH 01/13] apply: mark include/exclude options as NONEG

2018-11-04 Thread Jeff King
The options callback for "git apply --no-include" is not ready to handle the "unset" parameter, and as a result will segfault when it adds a NULL argument to the include list (likewise for "--no-exclude"). In theory this might be used to clear the list, but since b

  1   2   3   4   5   6   7   8   9   10   >