Re: Automatically marking conflicts are resolved

[Óscar Fuentes]

David Kastrup <address@hidden> writes:

>> That's not enough and too late. I wont commit the merge without testing
>> it first and meanwhile a clear separation of conflicted areas is useful.
>
> Uh, why would that be too late?  Before committing the merge, git diff
> lists all merge conflicts.  After committing the merge, the information
> is in the commit message.  The commit can still be amended.
>
> Whether or not you choose to commit first, test later (after all, a
> commit is not the same as an upstream push and can always be amended) or
> test first, commit later, the information is readily available.

I'm wary of using commits as temporary storage for work-in-progress on
merges or any other atomic change. A distraction at the wrong moment may
cause big trouble. There is a policy here that says that, except for
experimental throw-away projects, all changes must pass some tests
before committing them.

Also it is convenient to have the diff updated as you work on fixing the
merge, with the merge-specific diff indicators.