* [PATCH] Kill git-resolve.sh
@ 2006-09-23 19:55 Petr Baudis
2006-09-23 22:12 ` Junio C Hamano
0 siblings, 1 reply; 5+ messages in thread
From: Petr Baudis @ 2006-09-23 19:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
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>
---
.gitignore | 1
Documentation/git-resolve.txt | 36 --------------
Documentation/git.txt | 3 -
Makefile | 2 -
git-resolve.sh | 108 -----------------------------------------
5 files changed, 1 insertions(+), 149 deletions(-)
diff --git a/.gitignore b/.gitignore
index 0ffe14a..f89bbc6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -92,7 +92,6 @@ git-repo-config
git-request-pull
git-rerere
git-reset
-git-resolve
git-rev-list
git-rev-parse
git-revert
diff --git a/Documentation/git-resolve.txt b/Documentation/git-resolve.txt
deleted file mode 100644
index 4e57c2b..0000000
--- a/Documentation/git-resolve.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-git-resolve(1)
-==============
-
-NAME
-----
-git-resolve - Merge two commits
-
-
-SYNOPSIS
---------
-'git-resolve' <current> <merged> <message>
-
-DESCRIPTION
------------
-Given two commits and a merge message, merge the <merged> commit
-into <current> commit, with the commit log message <message>.
-
-When <current> is a descendant of <merged>, or <current> is an
-ancestor of <merged>, no new commit is created and the <message>
-is ignored. The former is informally called "already up to
-date", and the latter is often called "fast forward".
-
-
-Author
-------
-Written by Linus Torvalds <torvalds@osdl.org> and
-Dan Holmsand <holmsand@gmail.com>.
-
-Documentation
---------------
-Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
-
-GIT
----
-Part of the gitlink:git[7] suite
-
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 744c38d..a2efd17 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -336,9 +336,6 @@ gitlink:git-rerere[1]::
gitlink:git-reset[1]::
Reset current HEAD to the specified state.
-gitlink:git-resolve[1]::
- Merge two commits.
-
gitlink:git-revert[1]::
Revert an existing commit.
diff --git a/Makefile b/Makefile
index 58848e4..6a7c408 100644
--- a/Makefile
+++ b/Makefile
@@ -169,7 +169,7 @@ SCRIPT_SH = \
git-merge-one-file.sh git-parse-remote.sh \
git-pull.sh git-rebase.sh \
git-repack.sh git-request-pull.sh git-reset.sh \
- git-resolve.sh git-revert.sh git-sh-setup.sh \
+ git-revert.sh git-sh-setup.sh \
git-tag.sh git-verify-tag.sh \
git-applymbox.sh git-applypatch.sh git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
diff --git a/git-resolve.sh b/git-resolve.sh
deleted file mode 100755
index a7bc680..0000000
--- a/git-resolve.sh
+++ /dev/null
@@ -1,108 +0,0 @@
-#!/bin/sh
-#
-# Copyright (c) 2005 Linus Torvalds
-#
-# Resolve two trees.
-#
-
-USAGE='<head> <remote> <merge-message>'
-. git-sh-setup
-
-dropheads() {
- rm -f -- "$GIT_DIR/MERGE_HEAD" \
- "$GIT_DIR/LAST_MERGE" || exit 1
-}
-
-head=$(git-rev-parse --verify "$1"^0) &&
-merge=$(git-rev-parse --verify "$2"^0) &&
-merge_name="$2" &&
-merge_msg="$3" || usage
-
-#
-# The remote name is just used for the message,
-# but we do want it.
-#
-if [ -z "$head" -o -z "$merge" -o -z "$merge_msg" ]; then
- usage
-fi
-
-dropheads
-echo $head > "$GIT_DIR"/ORIG_HEAD
-echo $merge > "$GIT_DIR"/LAST_MERGE
-
-common=$(git-merge-base $head $merge)
-if [ -z "$common" ]; then
- die "Unable to find common commit between" $merge $head
-fi
-
-case "$common" in
-"$merge")
- echo "Already up-to-date. Yeeah!"
- dropheads
- exit 0
- ;;
-"$head")
- echo "Updating from $head to $merge"
- git-read-tree -u -m $head $merge || exit 1
- git-update-ref -m "resolve $merge_name: Fast forward" \
- HEAD "$merge" "$head"
- git-diff-tree -p $head $merge | git-apply --stat
- dropheads
- exit 0
- ;;
-esac
-
-# We are going to make a new commit.
-git var GIT_COMMITTER_IDENT >/dev/null || exit
-
-# Find an optimum merge base if there are more than one candidates.
-LF='
-'
-common=$(git-merge-base -a $head $merge)
-case "$common" in
-?*"$LF"?*)
- echo "Trying to find the optimum merge base."
- G=.tmp-index$$
- best=
- best_cnt=-1
- for c in $common
- do
- rm -f $G
- GIT_INDEX_FILE=$G git-read-tree -m $c $head $merge \
- 2>/dev/null || continue
- # Count the paths that are unmerged.
- cnt=`GIT_INDEX_FILE=$G git-ls-files --unmerged | wc -l`
- if test $best_cnt -le 0 -o $cnt -le $best_cnt
- then
- best=$c
- best_cnt=$cnt
- if test "$best_cnt" -eq 0
- then
- # Cannot do any better than all trivial merge.
- break
- fi
- fi
- done
- rm -f $G
- common="$best"
-esac
-
-echo "Trying to merge $merge into $head using $common."
-git-update-index --refresh 2>/dev/null
-git-read-tree -u -m $common $head $merge || exit 1
-result_tree=$(git-write-tree 2> /dev/null)
-if [ $? -ne 0 ]; then
- echo "Simple merge failed, trying Automatic merge"
- git-merge-index -o git-merge-one-file -a
- if [ $? -ne 0 ]; then
- echo $merge > "$GIT_DIR"/MERGE_HEAD
- die "Automatic merge failed, fix up by hand"
- fi
- result_tree=$(git-write-tree) || exit 1
-fi
-result_commit=$(echo "$merge_msg" | git-commit-tree $result_tree -p $head -p $merge)
-echo "Committed merge $result_commit"
-git-update-ref -m "resolve $merge_name: In-index merge" \
- HEAD "$result_commit" "$head"
-git-diff-tree -p $head $result_commit | git-apply --stat
-dropheads
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] Kill git-resolve.sh
2006-09-23 19:55 [PATCH] Kill git-resolve.sh Petr Baudis
@ 2006-09-23 22:12 ` Junio C Hamano
2006-09-23 22:25 ` [PATCH] Deprecate git-resolve.sh Petr Baudis
` (2 more replies)
0 siblings, 3 replies; 5+ messages in thread
From: Junio C Hamano @ 2006-09-23 22:12 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH] Deprecate git-resolve.sh
2006-09-23 22:12 ` Junio C Hamano
@ 2006-09-23 22:25 ` Petr Baudis
2006-09-23 22:39 ` [PATCH] Kill git-resolve.sh Jakub Narebski
2006-09-24 13:00 ` Petr Baudis
2 siblings, 0 replies; 5+ messages in thread
From: Petr Baudis @ 2006-09-23 22:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
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. ;-)
This makes git-resolve.sh print a big deprecation warning and sleep a bit
for extra annoyance. It should be removed completely after the next release.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
I won't touch git-merge-recursive.py because I really have no clue how
those fancy merge drivers work.
git-resolve.sh | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/git-resolve.sh b/git-resolve.sh
index a7bc680..729ec65 100755
--- a/git-resolve.sh
+++ b/git-resolve.sh
@@ -5,6 +5,10 @@ #
# Resolve two trees.
#
+echo 'WARNING: This command is DEPRECATED and will be removed very soon.' >&2
+echo 'WARNING: Please use git-merge or git-pull instead.' >&2
+sleep 2
+
USAGE='<head> <remote> <merge-message>'
. git-sh-setup
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] Kill git-resolve.sh
2006-09-23 22:12 ` Junio C Hamano
2006-09-23 22:25 ` [PATCH] Deprecate git-resolve.sh Petr Baudis
@ 2006-09-23 22:39 ` Jakub Narebski
2006-09-24 13:00 ` Petr Baudis
2 siblings, 0 replies; 5+ messages in thread
From: Jakub Narebski @ 2006-09-23 22:39 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Kill git-resolve.sh
2006-09-23 22:12 ` Junio C Hamano
2006-09-23 22:25 ` [PATCH] Deprecate git-resolve.sh Petr Baudis
2006-09-23 22:39 ` [PATCH] Kill git-resolve.sh Jakub Narebski
@ 2006-09-24 13:00 ` Petr Baudis
2 siblings, 0 replies; 5+ messages in thread
From: Petr Baudis @ 2006-09-24 13:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Dear diary, on Sun, Sep 24, 2006 at 12:12:01AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> On a very related note, we should prepare plan to deprecate
> merge-recursive.py.
While we are busy deprecating and removing stuff, we should also:
* probably finally get rid of git-ssh-upload and git-ssh-pull
(mentioned in another thread already)
* make git-annotate alias to git-blame -c? (and probably print
a deprecation warning)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-09-24 13:01 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-09-23 19:55 [PATCH] Kill git-resolve.sh Petr Baudis
2006-09-23 22:12 ` Junio C Hamano
2006-09-23 22:25 ` [PATCH] Deprecate git-resolve.sh Petr Baudis
2006-09-23 22:39 ` [PATCH] Kill git-resolve.sh Jakub Narebski
2006-09-24 13:00 ` Petr Baudis
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).