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: [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