Re: first-class conflicts?

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 11, 2023, 01:31 UTC
Message-ID: <xmqqh6ltrs6t.fsf@gitster.g>
In-Reply-To: <ZUmJyFs7z7wdmLVK@mit.edu>

"Theodore Ts'o" <tytso@mit.edu> writes:

Show 10 quoted lines

> And if you attempt to commit the merge without resolving the
> conflicts, git won't let you:
>
>    error: Committing is not possible because you have unmerged files.
>    hint: Fix them up in the work tree, and then use 'git add/rm <file>'
>    hint: as appropriate to mark resolution and make a commit.
>
> So it's hard to miss the indications of the content conflict, because
> if you try to commit without resolving them, it's not a warning, it's
> an outright error.

Correct but with a caveat: it is too easy for lazy folks to circumvent the safety by mistake with "commit -a".

I wonder if it would help users to add a new configuration option for those who want to live safer that tells "commit -a" to leave unmerged paths alone and require the unmerged paths to be added explicitly (which may have to extend to cover things like "add -u" and "add .").

Perhaps not. I often find myself doing "git add -u" after resolving conflicts and re-reading the result, without an explicit pathspec.