[PATCH 0/3] detecting delete/modechange conflicts

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

 



I was surprised to find that:

  # base commit
  echo base >file &&
  git add file &&
  git commit -m base &&

  # one side changes mode
  chmod +x file &&
  git commit -am executable &&

  # the other deletes the file
  git checkout -b other HEAD^ &&
  git rm file &&
  git commit -am removed &&

  git merge master

silently completes the merge, dropping the mode change. We detect
delete/modify conflicts, but not delete/modechange conflicts.  The
trivial index merge does catch it, but both the resolve and recursive
strategies resolve it silently in favor of the deletion.

After looking through the history and the list archive, I don't _think_
this was intentional, and we simply missed the case in both places. But
maybe somebody else knows something I don't. It seems like we should be
punting to the user under the general principle of stupid and safe
merges.

  [1/3]: t6031: move triple-rename test to t3030
  [2/3]: t6031: generalize for recursive and resolve strategies
  [3/3]: merge: detect delete/modechange conflict

-Peff
--
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



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