Re: [PATCH] Add tests to demonstrate update-index bug with core.symlinks/core.filemode

[lists@haller-berlin.de (Stefan Haller)]

Stefan Haller <lists@haller-berlin.de> wrote:

> Stefan Haller <lists@haller-berlin.de> wrote:
> 
> > There's a bug with the handling of the executable bit when core.filemode
> > is false: when you have an executable file that has unmerged changes,
> > and you stage it with "git update-index", the executable bit is lost.
> > If you stage it with "git add" instead, it works fine.
> 
> It turns out that the same bug exists for symlinks when core.symlink is
> false. Here's a patch that adds two tests that demonstrate the problems.
> (I suspect both have a similar cause, and/or a similar solution.)

OK, so I found commit 2031427 (git add: respect core.filemode with
unmerged entries), and the corresponding email thread at
<http://article.gmane.org/gmane.comp.version-control.git/51182/>, that
fixed the same bug for git add in 2007.

So maybe the fix for update-index is as simple as replacing the
cache_name_pos call in process_path() with index_name_pos_also_unmerged,
but I'm afraid of breaking something else in that area.  Advice welcome.

BTW, I'm not convinced that the logic in index_name_pos_also_unmerged of
always preferring stage 2 over stage 3 is good in all cases.  For the
case where a regular file is changed into a symlink or vice versa it
probably doesn't matter, as the resolution will always require human
intervention, but if the mode just changes from 644 to 755 or back, it
seems wrong to always pick the mode of "ours" over "theirs".  Instead,
it should pick whichever mode differs from stage 1, if the other
doesn't.


-- 
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/