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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 20/08/2019 19:32, Phillip Wood wrote:
On 20/08/2019 19:24, Junio C Hamano wrote:
Phillip Wood <phillip.wood123@xxxxxxxxx> 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux