Junio C Hamano wrote: > Petr Baudis <pasky@xxxxxxx> 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@xxxxxxx> > > 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html