Re: [PATCH] git.el: Make it easy to add unmerged files
- From
- Alexandre Julliard <julliard@winehq.org>
- Date
- Sep 2, 2009, 08:48 UTC
- Message-ID
- <87iqg120ln.fsf@wine.dyndns.org>
- In-Reply-To
- <4A9E0717.9040801@chromecode.com>
Martin Nordholts <martin@chromecode.com> writes:
Show 25 quoted lines
> On 08/30/2009 05:58 PM, Alexandre Julliard wrote:
>> Martin Nordholts <martin@chromecode.com> writes:
>>
>>> (Resending as I managed to mangle the previous patch despite trying not to...)
>>>
>>> It is nice and easy to git-add ignored and unknown files in a
>>> git-status buffer. Make it equally easy to add unmerged files which is
>>> a common use case.
>>
>> That's not quite what adding a file means in git.el, unmerged files are
>> considered added already, and marking them resolved is done through the
>> git-resolve-file command. Of course that was implemented before git
>> overloaded the meaning of git-add to mean git-update-index, so maybe we
>> should follow the trend and use git-add-file for all index updates. In
>> that case git-resolve-file should probably be removed.
>
> Since git instructs the user to use git-add for marking unmerged files
> as resolved ("After resolving the conflicts, mark the corrected paths
> with 'git add <paths>' or 'git rm <paths>' and commit the result.") and
> doesn't even mention git-update-index, I think we should change git.el
> accordingly.
>
> But why do we need to also remove and disable git-resolve-file from
> git.el? It doesn't hurt to keep that function and the keybinding, does
> it?It doesn't hurt much, but having two keybindings for the same thing is a bit wasteful since there aren't that many simple bindings available. If we remove it, it opens the door to later reusing the 'R' key for something else (a git-rename function would be the obvious choice).
-- Alexandre Julliard julliard@winehq.org