Re: [PATCH] Kill git-resolve.sh

[Jakub Narebski <jnareb@gmail.com>]

Junio C Hamano wrote:

> Petr Baudis <pasky@suse.cz> writes:
> 
>> 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.

On the fairly unrelated note, would the next release be 1.4.3, or would it
be 1.5.0 (the packed refs, the new index format, ...)?

-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git