From: Phillip Wood Date: Mon, 26 Aug 2019 15:09:20 GMT Subject: Re: [PATCH v4 2/2] apply: reload .gitattributes after patching it Message-ID: In-Reply-To: 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, 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