Stefan Haller <lists@xxxxxxxxxxxxxxxx> wrote: > Stefan Haller <lists@xxxxxxxxxxxxxxxx> 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/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html