Re: git commit/push and VC

[David Kastrup <dak@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Achim Gratz <Stromeko@nexgo.de>
>> Date: Thu, 20 Nov 2014 19:17:43 +0100
>> 
>> Eli Zaretskii writes:
>> > There are still issues that I'd like to be sure about before I fix
>> > them.  Would people please comment on these:
>> >
>> >   . the instructions say that a "git commit" is necessary even when
>> >     the merge is without conflicts, which AFAIK is incorrect with Git
>> 
>> In standard configuration a non-conflicted merge will be auto-committed,
>> yes.  As always, that default can be configured to instead stop before
>> the commit.
>
> OK, so if we are going to recommend to use "commit -a" (and actually
> we already do, see the Wiki), then I guess "git add" after resolving
> merge conflicts is also not necessary, right?  That is, instead of
> this:
>
>   git merge master
>   # resolve conflicts
>   git add file-you-changed
>   git commit -m "Merge from mainline."
>
> we should recommend this:
>
>   git merge master
>   # resolve conflicts
>   git commit -a -m "Merge from mainline."
>
> Is that correct?

I doubt that it works.  At any rate, Git does not distinguish between a
file with merge conflict markers and one without merge conflict markers
(which are valid file contents, after all).

It records unresolved conflicts in the index where they are overwritten
when doing git-add.  I haven't checked whether git commit -a will
actually overwrite a conflicted index.  If it does, we don't want to
recommend that error-prone workflow which is likely to record files with
unresolved conflicts as resolved.  If it doesn't, git commit -a will not
help.  smerge-mode, incidentally, adds the file in question
automatically anyway after all conflicts are resolved.  So if "# resolve
conflicts" implies use of smerge-mode, just git commit should be enough.

-- 
David Kastrup