Re: [RFC/PATCH] Add git-unresolve <paths>...

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

 



On Wed, 19 Apr 2006 13:01:28 -0700, Junio C Hamano wrote:
> 
> This is an attempt to address the issue raised on #git channel
> recently by Carl Worth.
...
> With git-unresolve <paths>..., the versions from our branch and
> their branch for specified blobs are placed in stage #2 and
> stage #3, without touching the working tree files.  This gives
> you the combined diff back for easier review, along with
> "diff --ours" and "diff --theirs".

Thanks. This looks quite interesting.

The name of git-unresolve seems reasonable on its own. In fact,
git-merge already uses "resolve" to describe manual conflict
resolution. For example:

	echo "Using the $best_strategy to prepare resolving by hand."

But this does introduce an unfortunate semantic clash with the
existing git-resolve, (which is an automated merge tool of some sort).
I don't know much about the existing git-resolve, but a recent thread
suggests it is a non-useful relic and people shouldn't be using it.

It would be nice if the complementary operations of manually
resolving and unresolving a merge conflict had complementary command
names. Would it be feasible to cop-opt the git-resolve name as a
synonym for update-index? (I certainly wouldn't mind a shorter name
for that operation.)

In fact, git-resolve could even go beyond being a synonym for
update-index. For example, it might also complain if it notices
conflict markers in the file. That seems like it would be a useful
convenience, (and no functionality would be robbed, since update-index
would still be available for anyone who needs to commit content that
looks like conflict markers).

Another thing I've been meaning to suggest soon is better output for
when an automatic merge fails. Currently, the final message is:

	Automatic merge failed; fix up by hand

That's not much guidance for a new user that perhaps is only used to
"git commit -a" and "git pull" that usually works. Without getting too
verbose, this might be improved with something like:

	Automatic merge failed; fix conflicts by hand, then commit the result

In addition, if git-commit is run with unmerged files, it could also
provide some extra guidance. Perhaps something like this, (just after
the list of "needs merge" files mentioned by git-update-index):

	Fix any conflicts in these files, then git-resolve each and commit again

-Carl

Attachment: pgpdlh33mNp57.pgp
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]