Add --rebase option to git-pull?

Add --rebase option to git-pull?

[Tom Clarke]

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

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

[Andreas Ericsson]

Tom Clarke wrote:
> 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

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

[Johannes Schindelin]

Hi,

On Thu, 30 Aug 2007, Tom Clarke wrote:

> 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

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

[Tom Clarke]

On 8/30/07, Andreas Ericsson <ae@op5.se> wrote:
> 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

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

[Tom Clarke]

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
        '')
                ;;

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

[Johannes Schindelin]

Hi,

On Thu, 30 Aug 2007, Tom Clarke wrote:

> 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

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

[Tom Clarke]

On 8/30/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 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

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

[Jakub Narebski]

Tom Clarke wrote:

> 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?

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

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

[Alex Riesen]

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"?

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

[Tom Clarke]

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"?
>
>

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

[Tom Clarke]

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:
> 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"?
> >
> >
>