* [PATCH] Add 'ours' merge strategy.
@ 2005-11-02 5:37 Junio C Hamano
2005-11-02 10:35 ` Johannes Schindelin
0 siblings, 1 reply; 3+ messages in thread
From: Junio C Hamano @ 2005-11-02 5:37 UTC (permalink / raw)
To: git
This adds the coolest merge strategy ever, "ours". It can take
arbitrary number of foreign heads and merge them into the
current branch, with the resulting tree always taken from our
branch head, hence its name.
What this means is that you can declare that the current branch
supersedes the development histories of other branches usnig
this merge strategy.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
This can be used to terminate an old maintenance branch without
leaving people's repositories behind. The old 0.99.8[a-z]
lettered releases were done from a maintenance branch that
forked off from the master branch at 0.99.8. The maintenance
branch for 0.99.9 has the tip of the last 0.99.8 maintenance
commit as one of the ancestors, as well as 0.99.9 commit, while
content-wise it forks off purely from 0.99.9.
I could have done the current maint branch like this,
immediately after 0.99.9:
$ git commit -m 'GIT 0.99.9'
$ git checkout -b newmaint
$ git pull -s ours . maint ;# still 0.99.8 maintenance
$ git checkout maint
$ git reset --hard newmaint ;# now based on both old maint and 0.99.9
$ git branch -d newmaint
.gitignore | 1 +
Makefile | 2 +-
git-merge-ours.sh | 7 +++++++
git-merge.sh | 2 +-
4 files changed, 10 insertions(+), 2 deletions(-)
create mode 100755 git-merge-ours.sh
applies-to: 9e58de65fa92cce061c8c4064141bc91856097ed
38431c13669432dfeac16a9142aff5a293331e9d
diff --git a/.gitignore b/.gitignore
index 927c89c..3edf6b4 100644
--- a/.gitignore
+++ b/.gitignore
@@ -50,6 +50,7 @@ git-merge-base
git-merge-index
git-merge-octopus
git-merge-one-file
+git-merge-ours
git-merge-recursive
git-merge-resolve
git-merge-stupid
diff --git a/Makefile b/Makefile
index 357cb3e..bda829e 100644
--- a/Makefile
+++ b/Makefile
@@ -89,7 +89,7 @@ SCRIPT_SH = \
git-tag.sh git-verify-tag.sh git-whatchanged.sh git.sh \
git-applymbox.sh git-applypatch.sh git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
- git-merge-resolve.sh git-grep.sh
+ git-merge-resolve.sh git-merge-ours.sh git-grep.sh
SCRIPT_PERL = \
git-archimport.perl git-cvsimport.perl git-relink.perl \
diff --git a/git-merge-ours.sh b/git-merge-ours.sh
new file mode 100755
index 0000000..a64704f
--- /dev/null
+++ b/git-merge-ours.sh
@@ -0,0 +1,7 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Junio C Hamano
+#
+# Pretend we resolved the heads, but declare our tree trumps everybody else.
+#
+exit 0
diff --git a/git-merge.sh b/git-merge.sh
index dd104db..b810fce 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -14,7 +14,7 @@ usage () {
# all_strategies='resolve recursive stupid octopus'
-all_strategies='recursive octopus resolve stupid'
+all_strategies='recursive octopus resolve stupid ours'
default_strategies='resolve octopus'
use_strategies=
---
0.99.9.GIT
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] Add 'ours' merge strategy.
2005-11-02 5:37 [PATCH] Add 'ours' merge strategy Junio C Hamano
@ 2005-11-02 10:35 ` Johannes Schindelin
2005-11-02 21:45 ` Daniel Barkalow
0 siblings, 1 reply; 3+ messages in thread
From: Johannes Schindelin @ 2005-11-02 10:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Hi,
On Tue, 1 Nov 2005, Junio C Hamano wrote:
> This can be used to terminate an old maintenance branch without
> leaving people's repositories behind.
How about optionally do something similar when git-rebase'ing? Especially
"pu"?
Ciao,
Dscho
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] Add 'ours' merge strategy.
2005-11-02 10:35 ` Johannes Schindelin
@ 2005-11-02 21:45 ` Daniel Barkalow
0 siblings, 0 replies; 3+ messages in thread
From: Daniel Barkalow @ 2005-11-02 21:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
On Wed, 2 Nov 2005, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 1 Nov 2005, Junio C Hamano wrote:
>
> > This can be used to terminate an old maintenance branch without
> > leaving people's repositories behind.
>
> How about optionally do something similar when git-rebase'ing? Especially
> "pu"?
For that, you'd additionally want to have the parent whose content was
ignored be listed as "optional" in a sense; users shouldn't have to
download all the commits that "pu" went through that have been superceded,
unless they're actually trying to get back from a superceded commit; the
log on that line isn't interesting (because all the useful messages are in
the rebased line, too, in potentially better versions), and so forth.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2005-11-02 21:45 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-02 5:37 [PATCH] Add 'ours' merge strategy Junio C Hamano
2005-11-02 10:35 ` Johannes Schindelin
2005-11-02 21:45 ` Daniel Barkalow
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).