[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Automatically marking conflicts are resolved

From: Óscar Fuentes
Subject: Re: Automatically marking conflicts are resolved
Date: Tue, 07 Jan 2014 14:06:49 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

David Kastrup <address@hidden> 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

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]