[Top][All Lists]

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

Re: Automatically marking conflicts are resolved

From: David Kastrup
Subject: Re: Automatically marking conflicts are resolved
Date: Tue, 07 Jan 2014 13:34:26 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Óscar Fuentes <address@hidden> writes:

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

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

> 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

reply via email to

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