Re: [PATCHv5 3/3] status: don't suggest "git rm" or "git add" if not appropriate

From: konglu@minatec.inpg.fr <konglu@minatec.inpg.fr>
Date: Jun 1, 2012, 14:08 UTC
Message-ID: <20120601160808.Horde.ij8nYXwdC4BPyMzILrtjxYA@webmail.minatec.grenoble-inp.fr>
In-Reply-To: <CABURp0qS-bDYTTgz75mQOOZsXzM1TkF_CNjaRNcXa4MYXAg0kA@mail.gmail.com>

Phil Hord <phil.hord@gmail.com> a écrit :

Show 8 quoted lines

>> +       } 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.