threads / discuss / 9707

Add --rebase option to git-pull?

Subject: Add --rebase option to git-pull?

## tl;dr

11 messages between Aug 30, 2007 and Aug 30, 2007.

replies: 10people: 5as markdown or json

Tom Clarke· Aug 30, 2007, 12:40 UTC · lore
Hi,

I'm in the process of setting up a git environment with a number of shared branches. To avoid putting unnecessary merges into the trunk, we'd like to normally use rebase when updating private branches. I wondered if it would be possible to automatically determine the correct remote branch to rebase against.

The most logical place to do this seemed to be in git-pull, so I experimented with adding a '--rebase' option, per the (rough) diff below.

I'm quite new to git, so is this a good strategy?
-Tom
commit 60b7318c2ebb7ee2bd1afb02f1fc925a29e1b214
Author: Tom Clarke <tom@u2i.com>
Date:   Thu Aug 30 14:39:34 2007 +0200
    Added --rebase option to pull
diff --git a/git-pull.sh b/git-pull.sh
index 5e96d1f..233a1d9 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -15,7 +15,7 @@ cd_to_toplevel
 test -z "$(git ls-files -u)" ||
        die "You are in the middle of a conflicted merge."

-strategy_args= no_summary= no_commit= squash=
+strategy_args= no_summary= no_commit= squash= rebase=false
 while case "$#,$1" in 0) break ;; *,-*) ;; *) break ;; esac
 do
        case "$1" in
@@ -29,6 +29,8 @@ do
                no_commit=--no-commit ;;
        --sq|--squ|--squa|--squas|--squash)
                squash=--squash ;;
+       --re|--reb|--reba|--rebase)
+               rebase=true ;;
        -s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
                --strateg=*|--strategy=*|\
        -s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
@@ -119,5 +121,10 @@ then
 fi

 merge_name=$(git fmt-merge-msg <"$GIT_DIR/FETCH_HEAD") || exit
-exec git-merge $no_summary $no_commit $squash $strategy_args \
+if test $rebase != "false"
+then
+    exec git-rebase $strategy_args $merge_head
+else
+    exec git-merge $no_summary $no_commit $squash $strategy_args \
        "$merge_name" HEAD $merge_head
+fi
Andreas Ericsson· Aug 30, 2007, 13:07 UTC · re: Tom Clarke · lore

Re: Add --rebase option to git-pull?

Tom Clarke wrote:
Show 14 quoted lines
> Hi,
> 
> I'm in the process of setting up a git environment with a number of
> shared branches. To avoid putting unnecessary merges into the trunk,
> we'd like to normally use rebase when updating private branches. I
> wondered if it would be possible to automatically determine the
> correct remote branch to rebase against.
> 
> The most logical place to do this seemed to be in git-pull, so I
> experimented with adding a '--rebase' option, per the (rough) diff
> below.
> 
> I'm quite new to git, so is this a good strategy?
> 

If I read the patch correctly (which I may not, ofcourse), you're rebasing the upstream changes to on top of your own work. That's not something you can readily do, since the parentage chain in git is supposed to be immutable, so mutating the one you get from an already published source would be a horribly bad idea indeed.

You need to do it the other way around, so that you rebase your local changes onto the upstream HEAD prior to pushing.

If that's what the patch does, then I guess all is fine and dandy, although I think it'd be better to add the merge-strategy rebase or possibly rebase-ours or rebase-theirs, which can be given as arguments to git-pull.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
Tom Clarke· Aug 30, 2007, 13:17 UTC · re: Andreas Ericsson · lore

Re: Add --rebase option to git-pull?

On 8/30/07, Andreas Ericsson <ae@op5.se> wrote:
Show 5 quoted lines
> If I read the patch correctly (which I may not, ofcourse), you're
> rebasing the upstream changes to on top of your own work. That's
> not something you can readily do, since the parentage chain in
> git is supposed to be immutable, so mutating the one you get from
> an already published source would be a horribly bad idea indeed.

It's intended to (and appears to) rebase on top of $merge_head, which would typically be something like origin/master or origin/topics/my_topic or something. I just noticed I don't need the $strategy_args which might be confusing.

> If that's what the patch does, then I guess all is fine and dandy,
> although I think it'd be better to add the merge-strategy rebase
> or possibly rebase-ours or rebase-theirs, which can be given as
> arguments to git-pull.
Ok, makes sense.
-Tom
Johannes Schindelin· Aug 30, 2007, 13:16 UTC · re: Tom Clarke · lore

Re: Add --rebase option to git-pull?

Hi,
On Thu, 30 Aug 2007, Tom Clarke wrote:
Show 9 quoted lines
> I'm in the process of setting up a git environment with a number of 
> shared branches. To avoid putting unnecessary merges into the trunk, 
> we'd like to normally use rebase when updating private branches. I 
> wondered if it would be possible to automatically determine the correct 
> remote branch to rebase against.
> 
> The most logical place to do this seemed to be in git-pull, so I 
> experimented with adding a '--rebase' option, per the (rough) diff 
> below.

In my TODO, there is "add the 'rebase' strategy". It is definitely something post-1.5.3, so I do not look into it. But the most logical place for me would be to have a strategy 'rebase'. IOW a git-merge-rebase.sh.

Ciao, Dscho

Tom Clarke· Aug 30, 2007, 15:10 UTC · re: Johannes Schindelin · lore

Re: Add --rebase option to git-pull?

On 8/30/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> In my TODO, there is "add the 'rebase' strategy".  It is definitely
> something post-1.5.3, so I do not look into it.  But the most logical
> place for me would be to have a strategy 'rebase'.  IOW a
> git-merge-rebase.sh.

The following is my first naive attempt, is this the kind of thing you were thinking of?

In addition to running the rebase, I changed the merge script to prevent the update-ref as this is (it seems) inappropriate as it wasn't really a merge we did.

I'm not sure if any of the other arguments (other than remotes) to the merge script are applicable here.

-Tom
commit b68df7b3c31953216a03b8f34ffbc6d0c0927ea3
Author: Tom Clarke <tom@u2i.com>
Date:   Thu Aug 30 17:06:21 2007 +0200
    adding rebase merge strategy
diff --git a/.gitignore b/.gitignore
index 63c918c..dd1aa22 100644
--- a/.gitignore
+++ b/.gitignore
@@ -74,6 +74,7 @@ git-merge-tree
 git-merge-octopus
 git-merge-one-file
 git-merge-ours
+git-merge-rebase
 git-merge-recursive
 git-merge-resolve
 git-merge-stupid
diff --git a/Makefile b/Makefile
index 4eb4637..f6adca2 100644
--- a/Makefile
+++ b/Makefile
@@ -210,7 +210,7 @@ SCRIPT_SH = \
        git-sh-setup.sh \
        git-am.sh \
        git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
-       git-merge-resolve.sh git-merge-ours.sh \
+       git-merge-resolve.sh git-merge-ours.sh git-merge-rebase.sh \
        git-lost-found.sh git-quiltimport.sh git-submodule.sh \
        git-filter-branch.sh \
        git-stash.sh
diff --git a/git-merge-rebase.sh b/git-merge-rebase.sh
new file mode 100755
index 0000000..6140d38
--- /dev/null
+++ b/git-merge-rebase.sh
@@ -0,0 +1,32 @@
+#!/bin/sh
+# Resolve two trees with rebase
+
+# The first parameters up to -- are merge bases; the rest are heads.
+bases= head= remotes= sep_seen=
+for arg
+do
+       case ",$sep_seen,$head,$arg," in
+       *,--,)
+               sep_seen=yes
+               ;;
+       ,yes,,*)
+               head=$arg
+               ;;
+       ,yes,*)
+               remotes="$remotes$arg "
+               ;;
+       *)
+               bases="$bases$arg "
+               ;;
+       esac
+done
+
+# Give up if we are given more than two remotes -- not handling octopus.
+case "$remotes" in
+?*' '?*)
+       exit 2 ;;
+esac
+
+git update-index --refresh 2>/dev/null
+
+git rebase $remotes || exit 2
diff --git a/git-merge.sh b/git-merge.sh
index 3a01db0..02611f3 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -16,11 +16,12 @@ test -z "$(git ls-files -u)" ||
 LF='
 '

-all_strategies='recur recursive octopus resolve stupid ours subtree'
+all_strategies='recur recursive octopus resolve stupid ours subtree rebase'
 default_twohead_strategies='recursive'
 default_octopus_strategies='octopus'
 no_fast_forward_strategies='subtree ours'
 no_trivial_strategies='recursive recur subtree ours'
+no_update_ref='rebase'
 use_strategies=

 allow_fast_forward=t
@@ -81,11 +82,18 @@ finish () {
                        echo "No merge message -- not updating HEAD"
                        ;;
                *)
-                       git update-ref -m "$rlogm" HEAD "$1" "$head" || exit 1
+                       case " $wt_strategy " in
+                       *" $no_update_ref "*)
+                               ;;
+                       *)
+                               git update-ref -m "$rlogm" HEAD "$1"
"$head" || exit 1
+                               ;;
+                       esac
                        ;;
                esac
                ;;
        esac
+
        case "$1" in
        '')
                ;;
Johannes Schindelin· Aug 30, 2007, 15:23 UTC · re: Tom Clarke · lore

Re: Add --rebase option to git-pull?

Hi,
On Thu, 30 Aug 2007, Tom Clarke wrote:
Show 8 quoted lines
> On 8/30/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > In my TODO, there is "add the 'rebase' strategy".  It is definitely
> > something post-1.5.3, so I do not look into it.  But the most logical
> > place for me would be to have a strategy 'rebase'.  IOW a
> > git-merge-rebase.sh.
> 
> The following is my first naive attempt, is this the kind of thing you
> were thinking of?
Looks good to me except for:
> +git update-index --refresh 2>/dev/null
Maybe a test case would be in order, too...

Thanks, Dscho

Tom Clarke· Aug 30, 2007, 15:26 UTC · re: Johannes Schindelin · lore

Re: Add --rebase option to git-pull?

On 8/30/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 5 quoted lines
> Looks good to me except for:
>
> > +git update-index --refresh 2>/dev/null
>
> Maybe a test case would be in order, too...
Will do.  Thanks,
-Tom
Jakub Narebski· Aug 30, 2007, 16:54 UTC · re: Tom Clarke · lore

Re: Add --rebase option to git-pull?

Tom Clarke wrote:
> On 8/30/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 7 quoted lines
>> In my TODO, there is "add the 'rebase' strategy".  It is definitely
>> something post-1.5.3, so I do not look into it.  But the most logical
>> place for me would be to have a strategy 'rebase'.  IOW a
>> git-merge-rebase.sh.
> 
> The following is my first naive attempt, is this the kind of thing you
> were thinking of?

By the way, such strategy appeared some time ago on git mailing list IIRC as 'subjugate' (then renamed to 'rebase') merge strategy.

As with all good ideas (stash, submodules) the idea returns... :-)
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Alex Riesen· Aug 30, 2007, 20:22 UTC · re: Tom Clarke · lore

Re: Add --rebase option to git-pull?

Tom Clarke, Thu, Aug 30, 2007 17:10:31 +0200:
Show 5 quoted lines
> +# Give up if we are given more than two remotes -- not handling octopus.
> +case "$remotes" in
> +?*' '?*)
> +       exit 2 ;;
> +esac
Isn't it "given two and more remotes"?
Tom Clarke· Aug 30, 2007, 20:36 UTC · re: Alex Riesen · lore

Re: Add --rebase option to git-pull?

Indeed. Thanks :-).
-Tom
On 8/30/07, Alex Riesen <raa.lkml@gmail.com> wrote:
Show 10 quoted lines
> Tom Clarke, Thu, Aug 30, 2007 17:10:31 +0200:
> > +# Give up if we are given more than two remotes -- not handling octopus.
> > +case "$remotes" in
> > +?*' '?*)
> > +       exit 2 ;;
> > +esac
>
> Isn't it "given two and more remotes"?
>
>
Tom Clarke· Aug 30, 2007, 20:44 UTC · re: Tom Clarke · lore

Re: Add --rebase option to git-pull?

Actually, it looks I copied the same documentation bug from git-merge-resolve.sh and git merge-stupid.sh

-Tom
On 8/30/07, Tom Clarke <tom@u2i.com> wrote:
Show 16 quoted lines
> Indeed. Thanks :-).
>
> -Tom
>
> On 8/30/07, Alex Riesen <raa.lkml@gmail.com> wrote:
> > Tom Clarke, Thu, Aug 30, 2007 17:10:31 +0200:
> > > +# Give up if we are given more than two remotes -- not handling octopus.
> > > +case "$remotes" in
> > > +?*' '?*)
> > > +       exit 2 ;;
> > > +esac
> >
> > Isn't it "given two and more remotes"?
> >
> >
>

← back to recent threads