Re: Automatically marking conflicts are resolved

[David Kastrup <dak@gnu.org>]

Óscar Fuentes <ofv@wanadoo.es> writes:

> David Kastrup <dak@gnu.org> 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.

So what?  I repeat: at no point of time does the information become
unavailable.

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

You are confused.  A "policy" cannot cover what may be _committed_ since
commits are private to each user.  A policy can only cover what is
_pushed_ to a central resource.

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

So what?  Fix a file, git add it, and it disappears from the diff (which
shows the difference between index and work directory by default)
without affecting the state of the repository.

-- 
David Kastrup