Re: Automatically marking conflicts are resolved

["Óscar Fuentes" <ofv@wanadoo.es>]

David Kastrup <dak@gnu.org> writes:

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

Availability + convenience is better than availability alone.

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

Apparently you are not familiarized with safety operational procedures,
and you certainly don't know the workflow here, so your claim is
baseless.

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

Here, a file is not "fixed" until the whole set of "fixes" passes the
tests.

> git add it, and it disappears from the diff

This I want to avoid. When a merge contains conflicts, the diffs on the
"Unstaged changes" section of Magit contains the conflicts and,
eventually, my edits for resolving them. The non-conflicted files are on
the "Staged changes" section. I find this convenient because it
clearly separates the parts that required human intervention.

> (which
> shows the difference between index and work directory by default)
> without affecting the state of the repository.