| Message ID | 20190818184403.861907-3-sandals@crustytoothpaste.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Honor .gitattributes with rebase --am | expand |
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 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. Do you know why -m and -i aren't affected? > To ensure we write the correct data into the working tree, expire the > cache after each patch that touches a path ending in ".gitattributes". > > Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> > --- > apply.c | 7 +++++++ > convert.c | 9 ++++++++- > convert.h | 6 ++++++ > t/t3400-rebase.sh | 36 ++++++++++++++++++++++++++++++++++++ > 4 files changed, 57 insertions(+), 1 deletion(-) > > diff --git a/apply.c b/apply.c > index cde95369bb..d57bc635e4 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 skipped_patch = 0; > int res = 0; > + int flush_attributes = 0; > > state->patch_input_file = filename; > if (read_patch_file(&buf, fd) < 0) > @@ -4670,6 +4671,10 @@ static int apply_patch(struct apply_state *state, > patch_stats(state, patch); > *listp = patch; > listp = &patch->next; > + > + if ((patch->new_name && ends_with_path_components(patch->new_name, GITATTRIBUTES_FILE)) || > + (patch->old_name && ends_with_path_components(patch->old_name, GITATTRIBUTES_FILE))) > + flush_attributes = 1; style nit - these lines are very long compared to 80 characters > } > else { > if (state->apply_verbosity > verbosity_normal) > @@ -4746,6 +4751,8 @@ static int apply_patch(struct apply_state *state, > if (state->summary && state->apply_verbosity > verbosity_silent) > summary_patch_list(list); > > + if (flush_attributes) > + reset_parsed_attributes(); > end: > free_patch_list(list); > strbuf_release(&buf); > 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 */ > }; > > +static struct attr_check *check; I was concerned about the impact adding a file global if we ever want to multi-thread this for submodules, but looking through the file there are a couple of others already so this isn't creating a new problem. Best Wishes Phillip > + > static void convert_attrs(const struct index_state *istate, > struct conv_attrs *ca, const char *path) > { > - static struct attr_check *check; > struct attr_check_item *ccheck = NULL; > > if (!check) { > @@ -1339,6 +1340,12 @@ static void convert_attrs(const struct index_state *istate, > ca->crlf_action = CRLF_AUTO_INPUT; > } > > +void reset_parsed_attributes(void) > +{ > + attr_check_free(check); > + check = NULL; > +} > + > int would_convert_to_git_filter_fd(const struct index_state *istate, const char *path) > { > struct conv_attrs ca; > diff --git a/convert.h b/convert.h > index 831559f10d..3710969d43 100644 > --- a/convert.h > +++ b/convert.h > @@ -94,6 +94,12 @@ void convert_to_git_filter_fd(const struct index_state *istate, > int would_convert_to_git_filter_fd(const struct index_state *istate, > const char *path); > > +/* > + * Reset the internal list of attributes used by convert_to_git and > + * convert_to_working_tree. > + */ > +void reset_parsed_attributes(void); > + > /***************************************************************** > * > * Streaming conversion support > diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh > index 80b23fd326..23469cc789 100755 > --- a/t/t3400-rebase.sh > +++ b/t/t3400-rebase.sh > @@ -301,6 +301,42 @@ test_expect_success 'rebase --am and --show-current-patch' ' > ) > ' > > +test_expect_success 'rebase --am and .gitattributes' ' > + test_create_repo attributes && > + ( > + cd attributes && > + test_commit init && > + git config filter.test.clean "sed -e '\''s/smudged/clean/g'\''" && > + git config filter.test.smudge "sed -e '\''s/clean/smudged/g'\''" && > + > + test_commit second && > + git checkout -b test HEAD^ && > + > + echo "*.txt filter=test" >.gitattributes && > + git add .gitattributes && > + test_commit third && > + > + echo "This text is smudged." >a.txt && > + git add a.txt && > + test_commit fourth && > + > + git checkout -b removal HEAD^ && > + git rm .gitattributes && > + git add -u && > + test_commit fifth && > + git cherry-pick test && > + > + git checkout test && > + git rebase master && > + grep "smudged" a.txt && > + > + git checkout removal && > + git reset --hard && > + git rebase master && > + grep "clean" a.txt > + ) > +' > + > test_expect_success 'rebase--merge.sh and --show-current-patch' ' > test_create_repo conflict-merge && > ( >
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 */ >> }; >> +static struct attr_check *check; > > I was concerned about the impact adding a file global if we ever want to > multi-thread this for submodules, but looking through the file there are > a couple of others already so this isn't creating a new problem. Doh, I've just realized it was static already - ignore that. One thing did occur to me though - does this patch reset attributes like the merge marker length (they're less critical though if there is a conflict after an attribute change it would be nice to have the correct length) or just the ones for filtering files? Best Wishes Phillip > > Best Wishes > > Phillip > >> + >> static void convert_attrs(const struct index_state *istate, >> struct conv_attrs *ca, const char *path) >> { >> - static struct attr_check *check; >> struct attr_check_item *ccheck = NULL; >> if (!check) { >> @@ -1339,6 +1340,12 @@ static void convert_attrs(const struct >> index_state *istate, >> ca->crlf_action = CRLF_AUTO_INPUT; >> } >> +void reset_parsed_attributes(void) >> +{ >> + attr_check_free(check); >> + check = NULL; >> +} >> + >> int would_convert_to_git_filter_fd(const struct index_state *istate, >> const char *path) >> { >> struct conv_attrs ca; >> diff --git a/convert.h b/convert.h >> index 831559f10d..3710969d43 100644 >> --- a/convert.h >> +++ b/convert.h >> @@ -94,6 +94,12 @@ void convert_to_git_filter_fd(const struct >> index_state *istate, >> int would_convert_to_git_filter_fd(const struct index_state *istate, >> const char *path); >> +/* >> + * Reset the internal list of attributes used by convert_to_git and >> + * convert_to_working_tree. >> + */ >> +void reset_parsed_attributes(void); >> + >> /***************************************************************** >> * >> * Streaming conversion support >> diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh >> index 80b23fd326..23469cc789 100755 >> --- a/t/t3400-rebase.sh >> +++ b/t/t3400-rebase.sh >> @@ -301,6 +301,42 @@ test_expect_success 'rebase --am and >> --show-current-patch' ' >> ) >> ' >> +test_expect_success 'rebase --am and .gitattributes' ' >> + test_create_repo attributes && >> + ( >> + cd attributes && >> + test_commit init && >> + git config filter.test.clean "sed -e >> '\''s/smudged/clean/g'\''" && >> + git config filter.test.smudge "sed -e >> '\''s/clean/smudged/g'\''" && >> + >> + test_commit second && >> + git checkout -b test HEAD^ && >> + >> + echo "*.txt filter=test" >.gitattributes && >> + git add .gitattributes && >> + test_commit third && >> + >> + echo "This text is smudged." >a.txt && >> + git add a.txt && >> + test_commit fourth && >> + >> + git checkout -b removal HEAD^ && >> + git rm .gitattributes && >> + git add -u && >> + test_commit fifth && >> + git cherry-pick test && >> + >> + git checkout test && >> + git rebase master && >> + grep "smudged" a.txt && >> + >> + git checkout removal && >> + git reset --hard && >> + git rebase master && >> + grep "clean" a.txt >> + ) >> +' >> + >> test_expect_success 'rebase--merge.sh and --show-current-patch' ' >> test_create_repo conflict-merge && >> ( >>
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 information, so if a > > file in a subsequent patch has attributes 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. > > 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 persist state. Should we move the merge-recursive code into the main process, we'll likely have the same problem there. > > diff --git a/apply.c b/apply.c > > index cde95369bb..d57bc635e4 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 skipped_patch = 0; > > int res = 0; > > + int flush_attributes = 0; > > state->patch_input_file = filename; > > if (read_patch_file(&buf, fd) < 0) > > @@ -4670,6 +4671,10 @@ static int apply_patch(struct apply_state *state, > > patch_stats(state, patch); > > *listp = patch; > > listp = &patch->next; > > + > > + if ((patch->new_name && ends_with_path_components(patch->new_name, GITATTRIBUTES_FILE)) || > > + (patch->old_name && ends_with_path_components(patch->old_name, GITATTRIBUTES_FILE))) > > + flush_attributes = 1; > > style nit - these lines are very long compared to 80 characters They are. They aren't two different from other lines in the file, and I thought that leaving them that way would preserve the similarities, but I can also wrap them. I'll send out a v5 with wrapped lines. > > 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 */ > > }; > > +static struct attr_check *check; > > I was concerned about the impact adding a file global if we ever want to > multi-thread this for submodules, but looking through the file there are a > couple of others already so this isn't creating a new problem. > > + > > static void convert_attrs(const struct index_state *istate, > > struct conv_attrs *ca, const char *path) > > { > > - static struct attr_check *check; > > struct attr_check_item *ccheck = NULL; > > if (!check) { > > @@ -1339,6 +1340,12 @@ static void convert_attrs(const struct index_state *istate, > > ca->crlf_action = CRLF_AUTO_INPUT; > > } The portion I've included above demonstrates that this was already a static variable, just one hidden in a function. So yeah, this is no worse than it already was.
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 *working_tree_encoding; /* Supported encoding or > > > default encoding if NULL */ > > > }; > > > +static struct attr_check *check; > > > > I was concerned about the impact adding a file global if we ever want to > > multi-thread this for submodules, but looking through the file there are > > a couple of others already so this isn't creating a new problem. > > Doh, I've just realized it was static already - ignore that. And I just realized that I didn't read the entire thread before responding. Sorry about that. > One thing did occur to me though - does this patch reset attributes like the > merge marker length (they're less critical though if there is a conflict > after an attribute change it would be nice to have the correct length) or > just the ones for filtering files? It resets "crlf", "ident", "filter", "eol", "text", and "working-tree-encoding". Things it doesn't reset include "whitespace", "export-ignore", "export-subst", "merge", and "conflict-marker-size". Of these, I think only the latter two are relevant. I'll update that in v5.
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 >>> 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 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. >> >> 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 persist state. The sequencer has been running in a single process for a while now. We do fork for 'git merge' sometimes when processing 'merge' commands but 'pick' commands are all done in a single process by calling do_recursive_merge(). Best Wishes Phillip > Should we move the merge-recursive code into the main process, we'll > likely have the same problem there. > >>> diff --git a/apply.c b/apply.c >>> index cde95369bb..d57bc635e4 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 skipped_patch = 0; >>> int res = 0; >>> + int flush_attributes = 0; >>> state->patch_input_file = filename; >>> if (read_patch_file(&buf, fd) < 0) >>> @@ -4670,6 +4671,10 @@ static int apply_patch(struct apply_state *state, >>> patch_stats(state, patch); >>> *listp = patch; >>> listp = &patch->next; >>> + >>> + if ((patch->new_name && ends_with_path_components(patch->new_name, GITATTRIBUTES_FILE)) || >>> + (patch->old_name && ends_with_path_components(patch->old_name, GITATTRIBUTES_FILE))) >>> + flush_attributes = 1; >> >> style nit - these lines are very long compared to 80 characters > > They are. They aren't two different from other lines in the file, and I > thought that leaving them that way would preserve the similarities, but > I can also wrap them. I'll send out a v5 with wrapped lines. > >>> 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 */ >>> }; >>> +static struct attr_check *check; >> >> I was concerned about the impact adding a file global if we ever want to >> multi-thread this for submodules, but looking through the file there are a >> couple of others already so this isn't creating a new problem. >>> + >>> static void convert_attrs(const struct index_state *istate, >>> struct conv_attrs *ca, const char *path) >>> { >>> - static struct attr_check *check; >>> struct attr_check_item *ccheck = NULL; >>> if (!check) { >>> @@ -1339,6 +1340,12 @@ static void convert_attrs(const struct index_state *istate, >>> ca->crlf_action = CRLF_AUTO_INPUT; >>> } > > The portion I've included above demonstrates that this was already a > static variable, just one hidden in a function. So yeah, this is no > worse than it already was. >
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 { >>>> const char *working_tree_encoding; /* Supported encoding or >>>> default encoding if NULL */ >>>> }; >>>> +static struct attr_check *check; >>> >>> I was concerned about the impact adding a file global if we ever want to >>> multi-thread this for submodules, but looking through the file there are >>> a couple of others already so this isn't creating a new problem. >> >> Doh, I've just realized it was static already - ignore that. > > And I just realized that I didn't read the entire thread before > responding. Sorry about that. > >> One thing did occur to me though - does this patch reset attributes like the >> merge marker length (they're less critical though if there is a conflict >> after an attribute change it would be nice to have the correct length) or >> just the ones for filtering files? > > It resets "crlf", "ident", "filter", "eol", "text", and > "working-tree-encoding". Things it doesn't reset include "whitespace", > "export-ignore", "export-subst", "merge", and "conflict-marker-size". > Of these, I think only the latter two are relevant. > > I'll update that in v5. Thanks, one other thought I had was that this is really a bug in 'am' rather than 'rebase'. There has been some talk of switching the default rabase backend to the sequencer so maybe it would be better to test 'am' rather than 'rebase' to ensure we still check 'am' is working properly after any switch in the rebase backend. (perhaps we should be testing rebase and rebase --interactive separately as well to prevent any future regressions I'm not sure) Best Wishes Phillip
Phillip Wood <phillip.wood123@gmail.com> 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 persist state. > > The sequencer has been running in a single process for a while now. We > do fork for 'git merge' sometimes when processing 'merge' commands but > 'pick' commands are all done in a single process by calling > do_recursive_merge(). > > Best Wishes > > Phillip > >> Should we move the merge-recursive code into the main process, we'll >> likely have the same problem there. So we actually have the same issue already?
On 20/08/2019 19:24, Junio C Hamano wrote: > Phillip Wood <phillip.wood123@gmail.com> 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 persist state. >> >> The sequencer has been running in a single process for a while now. We >> do fork for 'git merge' sometimes when processing 'merge' commands but >> 'pick' commands are all done in a single process by calling >> do_recursive_merge(). >> >> Best Wishes >> >> Phillip >> >>> Should we move the merge-recursive code into the main process, we'll >>> likely have the same problem there. > > So we actually have the same issue already? I don't think so, I modified Brian's test to call 'rebase -i' and it passes but no one seems to know why. Best Wishes Phillip
On 20/08/2019 19:32, Phillip Wood wrote: > On 20/08/2019 19:24, Junio C Hamano wrote: >> Phillip Wood <phillip.wood123@gmail.com> 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 persist state. >>> >>> The sequencer has been running in a single process for a while now. We >>> do fork for 'git merge' sometimes when processing 'merge' commands but >>> 'pick' commands are all done in a single process by calling >>> do_recursive_merge(). >>> >>> Best Wishes >>> >>> Phillip >>> >>>> Should we move the merge-recursive code into the main process, we'll >>>> likely have the same problem there. >> >> So we actually have the same issue already? > > I don't think so, I modified Brian's test to call 'rebase -i' and it > passes but no one seems to know why. 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 the end of the function. This has the effect of dropping all loaded attributes as git_attr_set_direction() calls drop_all_attr_stacks() when the direction is changed. Best Wishes Phillip > Best Wishes > > Phillip
Phillip Wood <phillip.wood123@gmail.com> 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 > the end of the function. This has the effect of dropping all loaded > attributes as git_attr_set_direction() calls drop_all_attr_stacks() > when the direction is changed. Ah, OK (and thanks), so it was working by accident ;-)
diff --git a/apply.c b/apply.c index cde95369bb..d57bc635e4 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 skipped_patch = 0; int res = 0; + int flush_attributes = 0; state->patch_input_file = filename; if (read_patch_file(&buf, fd) < 0) @@ -4670,6 +4671,10 @@ static int apply_patch(struct apply_state *state, patch_stats(state, patch); *listp = patch; listp = &patch->next; + + if ((patch->new_name && ends_with_path_components(patch->new_name, GITATTRIBUTES_FILE)) || + (patch->old_name && ends_with_path_components(patch->old_name, GITATTRIBUTES_FILE))) + flush_attributes = 1; } else { if (state->apply_verbosity > verbosity_normal) @@ -4746,6 +4751,8 @@ static int apply_patch(struct apply_state *state, if (state->summary && state->apply_verbosity > verbosity_silent) summary_patch_list(list); + if (flush_attributes) + reset_parsed_attributes(); end: free_patch_list(list); strbuf_release(&buf); 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 */ }; +static struct attr_check *check; + static void convert_attrs(const struct index_state *istate, struct conv_attrs *ca, const char *path) { - static struct attr_check *check; struct attr_check_item *ccheck = NULL; if (!check) { @@ -1339,6 +1340,12 @@ static void convert_attrs(const struct index_state *istate, ca->crlf_action = CRLF_AUTO_INPUT; } +void reset_parsed_attributes(void) +{ + attr_check_free(check); + check = NULL; +} + int would_convert_to_git_filter_fd(const struct index_state *istate, const char *path) { struct conv_attrs ca; diff --git a/convert.h b/convert.h index 831559f10d..3710969d43 100644 --- a/convert.h +++ b/convert.h @@ -94,6 +94,12 @@ void convert_to_git_filter_fd(const struct index_state *istate, int would_convert_to_git_filter_fd(const struct index_state *istate, const char *path); +/* + * Reset the internal list of attributes used by convert_to_git and + * convert_to_working_tree. + */ +void reset_parsed_attributes(void); + /***************************************************************** * * Streaming conversion support diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh index 80b23fd326..23469cc789 100755 --- a/t/t3400-rebase.sh +++ b/t/t3400-rebase.sh @@ -301,6 +301,42 @@ test_expect_success 'rebase --am and --show-current-patch' ' ) ' +test_expect_success 'rebase --am and .gitattributes' ' + test_create_repo attributes && + ( + cd attributes && + test_commit init && + git config filter.test.clean "sed -e '\''s/smudged/clean/g'\''" && + git config filter.test.smudge "sed -e '\''s/clean/smudged/g'\''" && + + test_commit second && + git checkout -b test HEAD^ && + + echo "*.txt filter=test" >.gitattributes && + git add .gitattributes && + test_commit third && + + echo "This text is smudged." >a.txt && + git add a.txt && + test_commit fourth && + + git checkout -b removal HEAD^ && + git rm .gitattributes && + git add -u && + test_commit fifth && + git cherry-pick test && + + git checkout test && + git rebase master && + grep "smudged" a.txt && + + git checkout removal && + git reset --hard && + git rebase master && + grep "clean" a.txt + ) +' + test_expect_success 'rebase--merge.sh and --show-current-patch' ' test_create_repo conflict-merge && (
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 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. To ensure we write the correct data into the working tree, expire the cache after each patch that touches a path ending in ".gitattributes". Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> --- apply.c | 7 +++++++ convert.c | 9 ++++++++- convert.h | 6 ++++++ t/t3400-rebase.sh | 36 ++++++++++++++++++++++++++++++++++++ 4 files changed, 57 insertions(+), 1 deletion(-)