Phil Hord <phil.hord@xxxxxxxxx> a écrit :
+ } else if (!del_mod_conflict && !not_deleted) {
+ status_printf_ln(s, c, _(" (use \"git rm
<file>...\" to mark resolution)"));
Why should I be bothered when both sides delete the same file? Does
this case only occur when each side has made different changes to the
file prior to deleting it, or does it occur any time each commit has
deleted the same exact file?
If both sides delete the same file with "git rm", this case does not occur
because there is no conflict when merging. However, it can occur when
both sides rename the file and then merge.
As this patch highlights, the only expected resolution is to 'git rm'
the file; why can't git figure this out for me and continue on?
I agree. The only option for the user is to run "git rm". You also have
to type the whole name of the deleted file as you can't tab for completion
and you can't avoid it as it's part of "unmerged path" (so you have to
resolve the current index). It would be great if git could figure it by
itself so we don't have to go through this process. Nevertheless, the
current display of the advice shows "git add" which can infer that you
can still recover the deleted file, which is not the case. At least, with
this code, the user will avoid this confusion.
--
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