Re: [PATCH] Kill git-resolve.sh

From: Junio C Hamano <junkio@cox.net>
Date: Sep 23, 2006, 22:12 UTC
Message-ID: <7v64fensge.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060923195530.5570.23774.stgit@machine.or.cz>

Petr Baudis <pasky@suse.cz> writes:

Show 7 quoted lines

> Seriously, is anyone still using this thing? It's collecting dust and
> blocking the name for something potentially useful like a tool for
> user-friendly marking of resolved conflicts or resolving index conflicts.
>
> We've loved you when Git was young, now thank you and please go away. ;-)
>
> Signed-off-by: Petr Baudis <pasky@suse.cz>

I've always wanted to do this at some point. Perhaps add a big red warning to git-resolve.sh right now and say "after the next 'master' release this will go away" to its stdout for a few weeks to find out who screams?

On a very related note, we should prepare plan to deprecate merge-recursive.py. My preference is:

	(1) rename merge-recursive.py to merge-recursive-old.py,
	    make it available as "recursive-old" strategy.

            install git-merge-recur as git-merge-recursive.
            Calling for "recur" or "recursive" strategy gets the
            same thing from this point on.

	(2) remove merge-recur synonym once people who are using
            "USE_RECUR_FOR_RECURSIVE" or "merge.twohead = recur"
            to use the bleeding edge migrate.

and I think step (1) can happen fairly soon. Maybe immediately after the next release from the "master".

Perhaps that is the good timing to remove git-resolve.sh as well. Or maybe immediately before that release? I dunno, and I do not think anybody cares really much.