Re: [PATCH] Kill git-resolve.sh
- From
Jakub Narebski <jnareb@gmail.com>
- Date
- Sep 23, 2006, 22:39 UTC
- Message-ID
- <ef4d3d$7vk$2@sea.gmane.org>
- In-Reply-To
- <7v64fensge.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
Show 35 quoted lines
> 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