threads / patch / 2313

patchRe: [PATCH] Add 'ours' merge strategy.

Subject: Re: [PATCH] Add 'ours' merge strategy.

## tl;dr

3 messages between Nov 2, 2005 and Nov 2, 2005. Diffs are folded; open one to read it.

replies: 2people: 3as markdown or json

Junio C Hamano· Nov 2, 2005, 05:37 UTC · lore

[PATCH] Add 'ours' merge strategy.

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

Show changes to 4 files +10 −2

.gitignore, Makefile, git-merge-ours.sh, git-merge.sh

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
Johannes Schindelin· Nov 2, 2005, 10:35 UTC · re: Junio C Hamano · lore
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

Daniel Barkalow· Nov 2, 2005, 21:45 UTC · re: Johannes Schindelin · lore
On Wed, 2 Nov 2005, Johannes Schindelin wrote:
Show 9 quoted lines
> 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*

← back to recent threads