threads / patch / 10466

patchTeach 'git pull' the '--rebase' option

Subject: [PATCH] Teach 'git pull' the '--rebase' option

## tl;dr

32 messages between Oct 25, 2007 and Dec 3, 2007. Diffs are folded; open one to read it.

replies: 31people: 14as markdown or json

Johannes Schindelin· Oct 25, 2007, 22:54 UTC · lore

When calling 'git pull' with the '--rebase' option, it performs a fetch + rebase instead of a fetch + pull.

This behavior is more desirable than fetch + pull when a topic branch is ready to be submitted.

fetch + rebase might also be considered a better workflow with shared repositories in any case, or for contributors to a centrally managed project, such as Wine -- or Git.

For your convenience, you can set the default behavior for a branch by defining the config variable branch.<name>.rebase, which is interpreted as a bool. This setting can be overridden on the command line by --rebase and --no-rebase.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/git-pull.txt |    6 ++++++
 git-pull.sh                |   11 ++++++++++-
 t/t5520-pull.sh            |   22 ++++++++++++++++++++++
 3 files changed, 38 insertions(+), 1 deletions(-)
Show changes to 3 files +38 −1

Documentation/git-pull.txt, git-pull.sh, t/t5520-pull.sh

diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index e1eb2c1..c3ce8ee 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -33,6 +33,12 @@ include::urls-remotes.txt[]
 
 include::merge-strategies.txt[]
 
+\--rebase::
+	Instead of a merge, perform a rebase after fetching.
+
+\--no-rebase::
+	Override earlier \--rebase.
+
 DEFAULT BEHAVIOUR
 -----------------
 
diff --git a/git-pull.sh b/git-pull.sh
index 74bfc16..b5ecb80 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -16,6 +16,9 @@ test -z "$(git ls-files -u)" ||
 	die "You are in the middle of a conflicted merge."
 
 strategy_args= no_summary= no_commit= squash=
+curr_branch=$(git symbolic-ref -q HEAD)
+curr_branch_short=$(echo "$curr_branch" | sed "s|refs/heads/||")
+rebase=$(git config --bool branch.$curr_branch_short.rebase)
 while :
 do
 	case "$1" in
@@ -43,6 +46,12 @@ do
 		esac
 		strategy_args="${strategy_args}-s $strategy "
 		;;
+	-r|--r|--re|--reb|--reba|--rebas|--rebase)
+		rebase=true
+		;;
+	--no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)
+		rebase=false
+		;;
 	-h|--h|--he|--hel|--help)
 		usage
 		;;
@@ -86,7 +95,6 @@ merge_head=$(sed -e '/	not-for-merge	/d' \
 
 case "$merge_head" in
 '')
-	curr_branch=$(git symbolic-ref -q HEAD)
 	case $? in
 	  0) ;;
 	  1) echo >&2 "You are not currently on a branch; you must explicitly"
@@ -133,5 +141,6 @@ then
 fi
 
 merge_name=$(git fmt-merge-msg <"$GIT_DIR/FETCH_HEAD") || exit
+test true = "$rebase" && exec git-rebase $merge_head
 exec git-merge $no_summary $no_commit $squash $strategy_args \
 	"$merge_name" HEAD $merge_head
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index 93eaf2c..52b3a0c 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -53,4 +53,26 @@ test_expect_success 'the default remote . should not break explicit pull' '
 	test `cat file` = modified
 '
 
+test_expect_success '--rebase' '
+	git branch to-rebase &&
+	echo modified again > file &&
+	git commit -m file file &&
+	git checkout to-rebase &&
+	echo new > file2 &&
+	git add file2 &&
+	git commit -m "new file" &&
+	git tag before-rebase &&
+	git pull --rebase . copy &&
+	test $(git rev-parse HEAD^) = $(git rev-parse copy) &&
+	test new = $(git show HEAD:file2)
+'
+
+test_expect_success 'branch.to-rebase.rebase' '
+	git reset --hard before-rebase &&
+	git config branch.to-rebase.rebase 1 &&
+	git pull . copy &&
+	test $(git rev-parse HEAD^) = $(git rev-parse copy) &&
+	test new = $(git show HEAD:file2)
+'
+
 test_done

-- 
1.5.3.4.1351.gee906
Linus Torvalds· Oct 25, 2007, 23:04 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Teach 'git pull' the '--rebase' option

On Thu, 25 Oct 2007, Johannes Schindelin wrote:
> 
> This behavior is more desirable than fetch + pull when a topic branch
> is ready to be submitted.

I'd like there to be some *big*warning* about how this destroys history and how you must not do this if you expose your history anywhere else.

I think it's a perfectly fine history, but if you have already pushed out your history somewhere else, you're now really screwed. In ways that a *real* merge will never screw you.

So the "--rebase" option really is only good for the lowest-level developers. And that should be documented.

		Linus
Johannes Schindelin· Oct 25, 2007, 23:10 UTC · re: Linus Torvalds · lore

Re: [PATCH] Teach 'git pull' the '--rebase' option

Hi,
On Thu, 25 Oct 2007, Linus Torvalds wrote:
Show 14 quoted lines
> On Thu, 25 Oct 2007, Johannes Schindelin wrote:
> > 
> > This behavior is more desirable than fetch + pull when a topic branch
> > is ready to be submitted.
> 
> I'd like there to be some *big*warning* about how this destroys history 
> and how you must not do this if you expose your history anywhere else.
> 
> I think it's a perfectly fine history, but if you have already pushed out 
> your history somewhere else, you're now really screwed. In ways that a 
> *real* merge will never screw you.
> 
> So the "--rebase" option really is only good for the lowest-level 
> developers. And that should be documented.
Fair enough.
How about this in the man page:
\--rebase::
	Instead of a merge, perform a rebase after fetching.
	*NOTE:* Never do this on branches you plan to publish!  This
	command will _destroy_ history, and is thus only suitable for
	topic branches to be submitted to another committer.

Ciao, Dscho

Linus Torvalds· Oct 25, 2007, 23:36 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Teach 'git pull' the '--rebase' option

On Fri, 26 Oct 2007, Johannes Schindelin wrote:
Show 6 quoted lines
> 
> \--rebase::
> 	Instead of a merge, perform a rebase after fetching.
> 	*NOTE:* Never do this on branches you plan to publish!  This
> 	command will _destroy_ history, and is thus only suitable for
> 	topic branches to be submitted to another committer.
Well, it really needs explanation of what "destroy" means.

Also, it's not strictly even necessary to publish things for this to cause problems. It's perfectly sufficient to just do development on two private developer machines, and do things like keeping the two machines in sync by pulling things between them manually...

So even "normal" developers who never publish a git tree to others may actually hit this issue.

			Linus
Linus Torvalds· Oct 25, 2007, 23:49 UTC · re: Linus Torvalds · lore

Re: [PATCH] Teach 'git pull' the '--rebase' option

On Thu, 25 Oct 2007, Linus Torvalds wrote:
> Also, it's not strictly even necessary to publish things for this to cause 
> problems. It's perfectly sufficient to just do development on two private 
> developer machines, and do things like keeping the two machines in sync by 
> pulling things between them manually...
.. or any branch use, for that matter.

I do agree that "git merge --rebase" is potentially convenient, I'm just not sure it's a great idea to document as such. People shouldn't do it unless they really *really* understand the implications, and I think the implications are much easier to understand if you instead teach them "fetch+rebase", and perhaps even keep the "merge --rebase" option entirely undocumented.

				Linus
Junio C Hamano· Oct 25, 2007, 23:54 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Teach 'git pull' the '--rebase' option

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 26 quoted lines
> On Thu, 25 Oct 2007, Linus Torvalds wrote:
>
>> On Thu, 25 Oct 2007, Johannes Schindelin wrote:
>> > 
>> > This behavior is more desirable than fetch + pull when a topic branch
>> > is ready to be submitted.
>> 
>> I'd like there to be some *big*warning* about how this destroys history 
>> and how you must not do this if you expose your history anywhere else.
>> 
>> I think it's a perfectly fine history, but if you have already pushed out 
>> your history somewhere else, you're now really screwed. In ways that a 
>> *real* merge will never screw you.
>> 
>> So the "--rebase" option really is only good for the lowest-level 
>> developers. And that should be documented.
>
> Fair enough.
>
> How about this in the man page:
>
> \--rebase::
> 	Instead of a merge, perform a rebase after fetching.
> 	*NOTE:* Never do this on branches you plan to publish!  This
> 	command will _destroy_ history, and is thus only suitable for
> 	topic branches to be submitted to another committer.
Nits.
(1) This "operation" will "rewrite"  history.
    You are not describing a command, but just one mode of operation
    of a command, whose other modes of operation do not share this
    history altering behaviour.
    The history is rewritten and made hard to work with for others
    who have previous incarnation of that history.  If it happens
    that nobody shared that previously published history nobody
    needs to suffer.  In that sense, there is something _usable_
    depending on who you are.  Destroy feels a bit too strong a
    word.
(2) This is not suitable for people who publish their trees and
    let others fetch and work off of them.
    Rebase is fine for e-mail submitting contributors as your
    description above suggests, but as your proposed commit log
    message said, it is also perfectly appropriate if your
    interaction with the outside world is "fetch + rebase +
    push".  You are not limited to "submitted to another
    committer".
Johannes Schindelin· Oct 26, 2007, 09:52 UTC · re: Junio C Hamano · lore

Re: [PATCH] Teach 'git pull' the '--rebase' option

Hi,
On Thu, 25 Oct 2007, Junio C Hamano wrote:
Show 33 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > On Thu, 25 Oct 2007, Linus Torvalds wrote:
> >
> >> On Thu, 25 Oct 2007, Johannes Schindelin wrote:
> >> > 
> >> > This behavior is more desirable than fetch + pull when a topic 
> >> > branch is ready to be submitted.
> >> 
> >> I'd like there to be some *big*warning* about how this destroys 
> >> history and how you must not do this if you expose your history 
> >> anywhere else.
> >> 
> >> I think it's a perfectly fine history, but if you have already pushed 
> >> out your history somewhere else, you're now really screwed. In ways 
> >> that a *real* merge will never screw you.
> >> 
> >> So the "--rebase" option really is only good for the lowest-level 
> >> developers. And that should be documented.
> >
> > Fair enough.
> >
> > How about this in the man page:
> >
> > \--rebase::
> > 	Instead of a merge, perform a rebase after fetching.
> > 	*NOTE:* Never do this on branches you plan to publish!  This
> > 	command will _destroy_ history, and is thus only suitable for
> > 	topic branches to be submitted to another committer.
> 
> Nits.
> 
> (1) This "operation" will "rewrite"  history.
Okay.
Show 9 quoted lines
> (2) This is not suitable for people who publish their trees and
>     let others fetch and work off of them.
> 
>     Rebase is fine for e-mail submitting contributors as your
>     description above suggests, but as your proposed commit log
>     message said, it is also perfectly appropriate if your
>     interaction with the outside world is "fetch + rebase +
>     push".  You are not limited to "submitted to another
>     committer".

Well, originally I did not want to document it at all. But I already heard the complaints about that in my inner ear. So I documented it, sparsely, in the hope that those who do not know the implications will not dare to use it. After Linus' complaint, I tried to make this shooing away more explicit.

I do not want to go into _that_ many details here, since the place to look for it is git-rebase.txt. Probably I should have done that in the first place.

So how about this instead:
\--rebase::
        Instead of a merge, perform a rebase after fetching.
        *NOTE:* This is a potentially _dangerous_ mode of operation.  
	It rewrites history, which does not bode well when you
	published that history already.  Do _not_ use this option
	unless you have	read gitlink:git-rebase[1] carefully.
Hmm?

Ciao, Dscho

Junio C Hamano· Nov 28, 2007, 00:11 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Teach 'git pull' the '--rebase' option

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 15 quoted lines
> ...
> I do not want to go into _that_ many details here, since the place to look 
> for it is git-rebase.txt.  Probably I should have done that in the first 
> place.
>
> So how about this instead:
>
> \--rebase::
>         Instead of a merge, perform a rebase after fetching.
>         *NOTE:* This is a potentially _dangerous_ mode of operation.  
> 	It rewrites history, which does not bode well when you
> 	published that history already.  Do _not_ use this option
> 	unless you have	read gitlink:git-rebase[1] carefully.
>
> Hmm?
Okay.
Johannes Schindelin· Nov 28, 2007, 13:11 UTC · re: Junio C Hamano · lore

[PATCH v2] Teach 'git pull' about --rebase

When calling 'git pull' with the '--rebase' option, it performs a fetch + rebase instead of a fetch + pull.

This behavior is more desirable than fetch + pull when a topic branch is ready to be submitted and needs to be update.

fetch + rebase might also be considered a better workflow with shared repositories in any case, or for contributors to a centrally managed repository, such as WINE's.

As a convenience, you can set the default behavior for a branch by defining the config variable branch.<name>.rebase, which is interpreted as a bool. This setting can be overridden on the command line by --rebase and --no-rebase.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
	On Tue, 27 Nov 2007, Junio C Hamano wrote:
	> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
	> 
	> > ...
	> > I do not want to go into _that_ many details here, since the 
	> > place to look for it is git-rebase.txt.  Probably I should 
	> > have done that in the first place.
	> >
	> > So how about this instead:
	> >
	> > \--rebase::
	> > 	Instead of a merge, perform a rebase after fetching.
	> > 	*NOTE:* This is a potentially _dangerous_ mode of operation.
	> > 	It rewrites history, which does not bode well when you
	> > 	published that history already.  Do _not_ use this option
	> > 	unless you have	read gitlink:git-rebase[1] carefully.
	> >
	> > Hmm?
	> 
	> Okay.
	I also added documentation for the branch.<name>.rebase variable.
 Documentation/config.txt   |    7 +++++++
 Documentation/git-pull.txt |   10 ++++++++++
 git-pull.sh                |   11 ++++++++++-
 t/t5520-pull.sh            |   22 ++++++++++++++++++++++
 4 files changed, 49 insertions(+), 1 deletions(-)
Show changes to 4 files +49 −1

Documentation/config.txt, Documentation/git-pull.txt, git-pull.sh, t/t5520-pull.sh

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 645514d..7bebc9a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -360,6 +360,13 @@ branch.<name>.mergeoptions::
 	option values containing whitespace characters are currently not
 	supported.
 
+branch.<name>.rebase::
+	When true, rebase the branch <name> on top of the fetched branch,
+	instead of merging the default branch from the default remote.
+	*NOTE*: this is a possibly dangerous operation; do *not* use
+	it unless you understand the implications (see gitlink:git-rebase[1]
+	for details).
+
 clean.requireForce::
 	A boolean to make git-clean do nothing unless given -f
 	or -n.   Defaults to true.
diff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt
index e1eb2c1..d4d26af 100644
--- a/Documentation/git-pull.txt
+++ b/Documentation/git-pull.txt
@@ -33,6 +33,16 @@ include::urls-remotes.txt[]
 
 include::merge-strategies.txt[]
 
+\--rebase::
+	Instead of a merge, perform a rebase after fetching.
+	*NOTE:* This is a potentially _dangerous_ mode of operation.
+	It rewrites history, which does not bode well when you
+	published that history already.  Do *not* use this option
+	unless you have read gitlink:git-rebase[1] carefully.
+
+\--no-rebase::
+	Override earlier \--rebase.
+
 DEFAULT BEHAVIOUR
 -----------------
 
diff --git a/git-pull.sh b/git-pull.sh
index 30fdc57..698e82b 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -17,6 +17,9 @@ test -z "$(git ls-files -u)" ||
 	die "You are in the middle of a conflicted merge."
 
 strategy_args= no_summary= no_commit= squash= no_ff=
+curr_branch=$(git symbolic-ref -q HEAD)
+curr_branch_short=$(echo "$curr_branch" | sed "s|refs/heads/||")
+rebase=$(git config --bool branch.$curr_branch_short.rebase)
 while :
 do
 	case "$1" in
@@ -52,6 +55,12 @@ do
 		esac
 		strategy_args="${strategy_args}-s $strategy "
 		;;
+	-r|--r|--re|--reb|--reba|--rebas|--rebase)
+		rebase=true
+		;;
+	--no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)
+		rebase=false
+		;;
 	-h|--h|--he|--hel|--help)
 		usage
 		;;
@@ -95,7 +104,6 @@ merge_head=$(sed -e '/	not-for-merge	/d' \
 
 case "$merge_head" in
 '')
-	curr_branch=$(git symbolic-ref -q HEAD)
 	case $? in
 	  0) ;;
 	  1) echo >&2 "You are not currently on a branch; you must explicitly"
@@ -142,5 +150,6 @@ then
 fi
 
 merge_name=$(git fmt-merge-msg <"$GIT_DIR/FETCH_HEAD") || exit
+test true = "$rebase" && exec git-rebase $merge_head
 exec git-merge $no_summary $no_commit $squash $no_ff $strategy_args \
 	"$merge_name" HEAD $merge_head
diff --git a/t/t5520-pull.sh b/t/t5520-pull.sh
index 93eaf2c..52b3a0c 100755
--- a/t/t5520-pull.sh
+++ b/t/t5520-pull.sh
@@ -53,4 +53,26 @@ test_expect_success 'the default remote . should not break explicit pull' '
 	test `cat file` = modified
 '
 
+test_expect_success '--rebase' '
+	git branch to-rebase &&
+	echo modified again > file &&
+	git commit -m file file &&
+	git checkout to-rebase &&
+	echo new > file2 &&
+	git add file2 &&
+	git commit -m "new file" &&
+	git tag before-rebase &&
+	git pull --rebase . copy &&
+	test $(git rev-parse HEAD^) = $(git rev-parse copy) &&
+	test new = $(git show HEAD:file2)
+'
+
+test_expect_success 'branch.to-rebase.rebase' '
+	git reset --hard before-rebase &&
+	git config branch.to-rebase.rebase 1 &&
+	git pull . copy &&
+	test $(git rev-parse HEAD^) = $(git rev-parse copy) &&
+	test new = $(git show HEAD:file2)
+'
+
 test_done

-- 
1.5.3.6.2064.g4e322
Jonathan del Strother· Nov 28, 2007, 13:15 UTC · re: Johannes Schindelin · lore

Re: [PATCH v2] Teach 'git pull' about --rebase

On 28 Nov 2007, at 13:11, Johannes Schindelin wrote:
Show 5 quoted lines
> When calling 'git pull' with the '--rebase' option, it performs a
> fetch + rebase instead of a fetch + pull.
>
> This behavior is more desirable than fetch + pull when a topic branch
> is ready to be submitted and needs to be update.
Don't you mean fetch + merge ?
Johannes Schindelin· Nov 28, 2007, 14:02 UTC · re: Jonathan del Strother · lore

Re: [PATCH v2] Teach 'git pull' about --rebase

Hi,
On Wed, 28 Nov 2007, Jonathan del Strother wrote:
Show 9 quoted lines
> On 28 Nov 2007, at 13:11, Johannes Schindelin wrote:
> 
> > When calling 'git pull' with the '--rebase' option, it performs a
> > fetch + rebase instead of a fetch + pull.
> > 
> > This behavior is more desirable than fetch + pull when a topic branch
> > is ready to be submitted and needs to be update.
> 
> Don't you mean fetch + merge ?
Obviously.

Thanks, Dscho

Jakub Narebski· Nov 28, 2007, 13:19 UTC · re: Johannes Schindelin · lore

Re: [PATCH v2] Teach 'git pull' about --rebase

Johannes Schindelin wrote:
Show 13 quoted lines
> @@ -52,6 +55,12 @@ do
>                 esac
>                 strategy_args="${strategy_args}-s $strategy "
>                 ;;
> +       -r|--r|--re|--reb|--reba|--rebas|--rebase)
> +               rebase=true
> +               ;;
> +       --no-r|--no-re|--no-reb|--no-reba|--no-rebas|--no-rebase)
> +               rebase=false
> +               ;;
>         -h|--h|--he|--hel|--help)
>                 usage
>                 ;;
Hmmm... rebase doesn't use git-rev-parse --parseopt?
-- 
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
Steven Grimm· Nov 28, 2007, 20:35 UTC · re: Johannes Schindelin · lore

Re: [PATCH v2] Teach 'git pull' about --rebase

On Nov 28, 2007, at 5:11 AM, Johannes Schindelin wrote:
> As a convenience, you can set the default behavior for a branch by
> defining the config variable branch.<name>.rebase, which is
> interpreted as a bool.  This setting can be overridden on the command
> line by --rebase and --no-rebase.

I wonder if this shouldn't be branch.<name>.pulltype or something like that, so we can represent more than just "rebase or not." Values could be "rebase", "merge" (the default) and maybe even "manual" to specify that git-pull should neither merge nor rebase a particular branch even if it matches a wildcard refspec.

Not too sure about that last suggestion but it seems like there might be other settings than "rebase" and "merge" in the future even if that's not one of them.

-Steve
Johannes Schindelin· Nov 28, 2007, 20:40 UTC · re: Steven Grimm · lore

Re: [PATCH v2] Teach 'git pull' about --rebase

Hi,
On Wed, 28 Nov 2007, Steven Grimm wrote:
Show 11 quoted lines
> On Nov 28, 2007, at 5:11 AM, Johannes Schindelin wrote:
> > As a convenience, you can set the default behavior for a branch by 
> > defining the config variable branch.<name>.rebase, which is 
> > interpreted as a bool.  This setting can be overridden on the command 
> > line by --rebase and --no-rebase.
> 
> I wonder if this shouldn't be branch.<name>.pulltype or something like 
> that, so we can represent more than just "rebase or not." Values could 
> be "rebase", "merge" (the default) and maybe even "manual" to specify 
> that git-pull should neither merge nor rebase a particular branch even 
> if it matches a wildcard refspec.

I am not convinced that this is a good thing... We already have branch.<name>.mergeOptions for proper merges, and I want to make clear that this is about rebase, and not about merge.

Ciao, Dscho

Lars Hjemli· Nov 28, 2007, 21:10 UTC · re: Johannes Schindelin · lore

Re: [PATCH v2] Teach 'git pull' about --rebase

On 11/28/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
Show 10 quoted lines
> On Wed, 28 Nov 2007, Steven Grimm wrote:
> > I wonder if this shouldn't be branch.<name>.pulltype or something like
> > that, so we can represent more than just "rebase or not." Values could
> > be "rebase", "merge" (the default) and maybe even "manual" to specify
> > that git-pull should neither merge nor rebase a particular branch even
> > if it matches a wildcard refspec.
>
> I am not convinced that this is a good thing... We already have
> branch.<name>.mergeOptions for proper merges, and I want to make clear
> that this is about rebase, and not about merge.
Maybe branch.<name>.pullOptions ?

-- larsh

Junio C Hamano· Nov 28, 2007, 21:55 UTC · re: Lars Hjemli · lore

Re: [PATCH v2] Teach 'git pull' about --rebase

"Lars Hjemli" <hjemli@gmail.com> writes:
Show 13 quoted lines
> On 11/28/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> On Wed, 28 Nov 2007, Steven Grimm wrote:
>> > I wonder if this shouldn't be branch.<name>.pulltype or something like
>> > that, so we can represent more than just "rebase or not." Values could
>> > be "rebase", "merge" (the default) and maybe even "manual" to specify
>> > that git-pull should neither merge nor rebase a particular branch even
>> > if it matches a wildcard refspec.
>>
>> I am not convinced that this is a good thing... We already have
>> branch.<name>.mergeOptions for proper merges, and I want to make clear
>> that this is about rebase, and not about merge.
>
> Maybe branch.<name>.pullOptions ?

Maybe not make this part of git-pull at all? merge and rebase have totally different impact on the resulting history, so perhaps a separate command that is a shorthand for "git fetch && git rebase" may help unconfuse the users.

Johannes Schindelin· Nov 28, 2007, 21:58 UTC · re: Junio C Hamano · lore

Re: [PATCH v2] Teach 'git pull' about --rebase

Hi,
On Wed, 28 Nov 2007, Junio C Hamano wrote:
Show 20 quoted lines
> "Lars Hjemli" <hjemli@gmail.com> writes:
> 
> > On 11/28/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >> On Wed, 28 Nov 2007, Steven Grimm wrote:
> >> > I wonder if this shouldn't be branch.<name>.pulltype or something like
> >> > that, so we can represent more than just "rebase or not." Values could
> >> > be "rebase", "merge" (the default) and maybe even "manual" to specify
> >> > that git-pull should neither merge nor rebase a particular branch even
> >> > if it matches a wildcard refspec.
> >>
> >> I am not convinced that this is a good thing... We already have
> >> branch.<name>.mergeOptions for proper merges, and I want to make clear
> >> that this is about rebase, and not about merge.
> >
> > Maybe branch.<name>.pullOptions ?
> 
> Maybe not make this part of git-pull at all?  merge and rebase have
> totally different impact on the resulting history, so perhaps a separate
> command that is a shorthand for "git fetch && git rebase" may help
> unconfuse the users.

Not so sure about that. We already have too many commands, according to some outspoken people, and this would add to it.

Besides, the operation "pull" is about getting remote changes incorporated in your current branch. IMHO "pull = fetch + merge" is only a technical detail, and we should not be bound by it too much.

Ciao, Dscho

Steven Grimm· Nov 28, 2007, 22:06 UTC · re: Johannes Schindelin · lore

Re: [PATCH v2] Teach 'git pull' about --rebase

On Nov 28, 2007, at 1:58 PM, Johannes Schindelin wrote:
Show 5 quoted lines
> Besides, the operation "pull" is about getting remote changes  
> incorporated
> in your current branch.  IMHO "pull = fetch + merge" is only a  
> technical
> detail, and we should not be bound by it too much.

Yeah, I agree. I almost never use "pull" as is because I almost always want to rebase. That is, it's basically clutter for me as a command right now, and it would remain so even if a separate fetch+rebase command were added.

I think this may be a difference in perspective based on how one uses git. If I were an integrator I would probably use "pull" as is a lot more because I would want the merges represented explicitly in my history. But most of the time I'm working as a leaf node in the tree of repositories, interacting only with a central integration repo, and I basically never want a give-me-the-remote-changes operation (which is really more of a "sync me up with the latest changes from the rest of the team" operation) to put a merge in my history.

What's more, when I'm introducing git to new people in my environment, right now I tell them about fetch and rebase and pretty much have to tell them to avoid running "pull" until they're comfortable with git, since I know their histories would be full of meaningless merges otherwise. It'd be nice to have new people run one less command as part of their normal day-to-day work.

-Steve
J. Bruce Fields· Nov 28, 2007, 22:33 UTC · re: Johannes Schindelin · lore

Re: [PATCH v2] Teach 'git pull' about --rebase

On Wed, Nov 28, 2007 at 09:58:52PM +0000, Johannes Schindelin wrote:
Show 27 quoted lines
> Hi,
> 
> On Wed, 28 Nov 2007, Junio C Hamano wrote:
> 
> > "Lars Hjemli" <hjemli@gmail.com> writes:
> > 
> > > On 11/28/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > >> On Wed, 28 Nov 2007, Steven Grimm wrote:
> > >> > I wonder if this shouldn't be branch.<name>.pulltype or something like
> > >> > that, so we can represent more than just "rebase or not." Values could
> > >> > be "rebase", "merge" (the default) and maybe even "manual" to specify
> > >> > that git-pull should neither merge nor rebase a particular branch even
> > >> > if it matches a wildcard refspec.
> > >>
> > >> I am not convinced that this is a good thing... We already have
> > >> branch.<name>.mergeOptions for proper merges, and I want to make clear
> > >> that this is about rebase, and not about merge.
> > >
> > > Maybe branch.<name>.pullOptions ?
> > 
> > Maybe not make this part of git-pull at all?  merge and rebase have
> > totally different impact on the resulting history, so perhaps a separate
> > command that is a shorthand for "git fetch && git rebase" may help
> > unconfuse the users.
> 
> Not so sure about that.  We already have too many commands, according to 
> some outspoken people, and this would add to it.

What they're really complaining about is the size and complexity of the interface, and the lack of a clearly identified subset for them to learn first.

This has so far mainly manifested itself in complaints about the number of commands, because that's currently where a lot of our complexity is. But they *will* complain about proliferation of commandline switches and config options too. (I've heard complaints about the number of switches required on the average cvs commandline, for example.)

We're stuck expanding the interface here, whether we expand it by another command or another commandline switch.

So, how do you decide whether to make it a new command or not?
	- Look at existing documentation that talks about pull: if that
	  documentation will still apply to the new pull, that weighs
	  for keeping it the same command.  If theat documentation would
	  apply only without having a certain config value set, then I
	  think it's better as a separate command.
	- Will this make it more or less simple to identify the subset
	  of the git syntax that a user will have to do a given job?  If
	  there are jobs for which someone might only ever need the new
	  fetch+rebase, or for which they would only ever need the
	  traditional pull, then I think it would keep the two separate,
	  to make it easier for a learner to skip over information about
	  the one they're not using.

I've got no proposal for an alternate name. All that comes to mind is the portmanteau "freebase", which is terrible....

--b.
J. Bruce Fields· Nov 28, 2007, 22:47 UTC · re: J. Bruce Fields · lore

Re: [PATCH v2] Teach 'git pull' about --rebase

On Wed, Nov 28, 2007 at 05:33:39PM -0500, J. Bruce Fields wrote:
Show 31 quoted lines
> What they're really complaining about is the size and complexity of the
> interface, and the lack of a clearly identified subset for them to learn
> first.
> 
> This has so far mainly manifested itself in complaints about the number
> of commands, because that's currently where a lot of our complexity is.
> But they *will* complain about proliferation of commandline switches and
> config options too.  (I've heard complaints about the number of switches
> required on the average cvs commandline, for example.)
> 
> We're stuck expanding the interface here, whether we expand it by
> another command or another commandline switch.
> 
> So, how do you decide whether to make it a new command or not?
> 
> 	- Look at existing documentation that talks about pull: if that
> 	  documentation will still apply to the new pull, that weighs
> 	  for keeping it the same command.  If theat documentation would
> 	  apply only without having a certain config value set, then I
> 	  think it's better as a separate command.
> 
> 	- Will this make it more or less simple to identify the subset
> 	  of the git syntax that a user will have to do a given job?  If
> 	  there are jobs for which someone might only ever need the new
> 	  fetch+rebase, or for which they would only ever need the
> 	  traditional pull, then I think it would keep the two separate,
> 	  to make it easier for a learner to skip over information about
> 	  the one they're not using.
> 
> I've got no proposal for an alternate name.  All that comes to mind is
> the portmanteau "freebase", which is terrible....

Actually, considering the second point: people that are using fetch+rebase don't necessarily need or (for now) want to understand pull at all. But they certainly *do* have to understand rebase. Would it be possible to add this to rebase instead of to pull?

	git rebase --url git://x.org/x.git master

where --url means "interpret <upstream> as a branch from the given remote repository.

That interacts poorly with --onto, though.
--b.
Johannes Schindelin· Nov 28, 2007, 23:12 UTC · re: J. Bruce Fields · lore

Re: [PATCH v2] Teach 'git pull' about --rebase

Hi,
On Wed, 28 Nov 2007, J. Bruce Fields wrote:
Show 6 quoted lines
> Would it be possible to add this to rebase instead of to pull?
> 
> 	git rebase --url git://x.org/x.git master
> 
> where --url means "interpret <upstream> as a branch from the given
> remote repository.
I was briefly considering it.

But the point is this: I know exactly if I want to rebase my branch onto upstream, or if I want to merge it. There is not much point in mixing the two.

So my rationale was: if we already have an existing framework to integrate remote changes with our current branch, why not just go ahead and use it? That's the reason BTW why I originally wanted a "rebase" merge stragegy. Even if it is not technically a merge.

I really rather have no user-friendly support for fetch+rebase (and utter a friendly, but loud curse everytime I made a "git pull" by mistake) than yet another command.

Ciao, Dscho

Junio C Hamano· Nov 28, 2007, 23:32 UTC · re: Johannes Schindelin · lore

Re: [PATCH v2] Teach 'git pull' about --rebase

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 8 quoted lines
> So my rationale was: if we already have an existing framework to integrate 
> remote changes with our current branch, why not just go ahead and use it?  
> That's the reason BTW why I originally wanted a "rebase" merge stragegy.  
> Even if it is not technically a merge.
>
> I really rather have no user-friendly support for fetch+rebase (and utter 
> a friendly, but loud curse everytime I made a "git pull" by mistake) than 
> yet another command.

I suspect that people who do not like the two modes of checkout will certainly not appreciate the overloading two behaviours to create different kind of histories and two different ways to continue when the integration do not go smoothly upon conflicts these two behaviours have.

However, I agree very much with an earlier comment made by Daniel about our UI being task oriented instead of being command oriented, and I actually consider it a good thing. So it does not bother me too much that "git pull --rebase" has a quite different workflow from the regular "merge" kind of pull.

So let's queue "pull --rebase" and see what happens.
J. Bruce Fields· Nov 28, 2007, 23:56 UTC · re: Junio C Hamano · lore

Re: [PATCH v2] Teach 'git pull' about --rebase

On Wed, Nov 28, 2007 at 03:32:49PM -0800, Junio C Hamano wrote:
Show 23 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > So my rationale was: if we already have an existing framework to integrate 
> > remote changes with our current branch, why not just go ahead and use it?  
> > That's the reason BTW why I originally wanted a "rebase" merge stragegy.  
> > Even if it is not technically a merge.
> >
> > I really rather have no user-friendly support for fetch+rebase (and utter 
> > a friendly, but loud curse everytime I made a "git pull" by mistake) than 
> > yet another command.
> 
> I suspect that people who do not like the two modes of checkout will
> certainly not appreciate the overloading two behaviours to create
> different kind of histories and two different ways to continue when the
> integration do not go smoothly upon conflicts these two behaviours have.
> 
> However, I agree very much with an earlier comment made by Daniel about
> our UI being task oriented instead of being command oriented, and I
> actually consider it a good thing.  So it does not bother me too much
> that "git pull --rebase" has a quite different workflow from the regular
> "merge" kind of pull.
> 
> So let's queue "pull --rebase" and see what happens.

What I'm really most worried about isn't the commandline switch but the config option--it makes the same commandlines silently behave in very different ways.

I really don't want every tutorial that mentions "git pull" to have to say "the following applies only if git.<current-branch>.rebase is false". And it'll be either that or risk having a lot of people saying "I typed in exactly that commandline, but this happened....".

A default to "false" does at least require positive acknowledgement, but if this is expected to be used by newbies, they're going to be told to set that config before they understand the difference it makes.

--b.
Johannes Schindelin· Nov 29, 2007, 00:16 UTC · re: J. Bruce Fields · lore

Re: [PATCH v2] Teach 'git pull' about --rebase

Hi,
On Wed, 28 Nov 2007, J. Bruce Fields wrote:
Show 37 quoted lines
> On Wed, Nov 28, 2007 at 03:32:49PM -0800, Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 
> > > So my rationale was: if we already have an existing framework to integrate 
> > > remote changes with our current branch, why not just go ahead and use it?  
> > > That's the reason BTW why I originally wanted a "rebase" merge stragegy.  
> > > Even if it is not technically a merge.
> > >
> > > I really rather have no user-friendly support for fetch+rebase (and utter 
> > > a friendly, but loud curse everytime I made a "git pull" by mistake) than 
> > > yet another command.
> > 
> > I suspect that people who do not like the two modes of checkout will
> > certainly not appreciate the overloading two behaviours to create
> > different kind of histories and two different ways to continue when the
> > integration do not go smoothly upon conflicts these two behaviours have.
> > 
> > However, I agree very much with an earlier comment made by Daniel about
> > our UI being task oriented instead of being command oriented, and I
> > actually consider it a good thing.  So it does not bother me too much
> > that "git pull --rebase" has a quite different workflow from the regular
> > "merge" kind of pull.
> > 
> > So let's queue "pull --rebase" and see what happens.
> 
> What I'm really most worried about isn't the commandline switch but the
> config option--it makes the same commandlines silently behave in very
> different ways.
> 
> I really don't want every tutorial that mentions "git pull" to have to
> say "the following applies only if git.<current-branch>.rebase is
> false".  And it'll be either that or risk having a lot of people saying
> "I typed in exactly that commandline, but this happened....".
> 
> A default to "false" does at least require positive acknowledgement, but
> if this is expected to be used by newbies, they're going to be told to
> set that config before they understand the difference it makes.
Hey, why not just special case "mergeOptions = rebaseInstead"?

Ciao, Dscho

Andreas Ericsson· Nov 29, 2007, 08:36 UTC · re: Junio C Hamano · lore

Re: [PATCH v2] Teach 'git pull' about --rebase

Junio C Hamano wrote:
Show 24 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
>> So my rationale was: if we already have an existing framework to integrate 
>> remote changes with our current branch, why not just go ahead and use it?  
>> That's the reason BTW why I originally wanted a "rebase" merge stragegy.  
>> Even if it is not technically a merge.
>>
>> I really rather have no user-friendly support for fetch+rebase (and utter 
>> a friendly, but loud curse everytime I made a "git pull" by mistake) than 
>> yet another command.
> 
> I suspect that people who do not like the two modes of checkout will
> certainly not appreciate the overloading two behaviours to create
> different kind of histories and two different ways to continue when the
> integration do not go smoothly upon conflicts these two behaviours have.
> 
> However, I agree very much with an earlier comment made by Daniel about
> our UI being task oriented instead of being command oriented, and I
> actually consider it a good thing.  So it does not bother me too much
> that "git pull --rebase" has a quite different workflow from the regular
> "merge" kind of pull.
> 
> So let's queue "pull --rebase" and see what happens.
>

I've used the --rebase option to git pull, explained it to my co-workers and also made sure they're using a version of git that has it. So far there hasn't been a single complaint about "git pull" being any harder to grok.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231
Nicolas Pitre· Nov 29, 2007, 03:23 UTC · re: J. Bruce Fields · lore

Re: [PATCH v2] Teach 'git pull' about --rebase

On Wed, 28 Nov 2007, J. Bruce Fields wrote:
Show 7 quoted lines
> On Wed, Nov 28, 2007 at 09:58:52PM +0000, Johannes Schindelin wrote:
> > Not so sure about that.  We already have too many commands, according to 
> > some outspoken people, and this would add to it.
> 
> What they're really complaining about is the size and complexity of the
> interface, and the lack of a clearly identified subset for them to learn
> first.

Well, the idea is that once all those plumbing commands are hidden away in some libexec dir, that makes a _lot_ of breathing room for a few more porcelain commands if needed.

Nicolas
Jon Loeliger· Nov 28, 2007, 21:59 UTC · re: Junio C Hamano · lore

Re: [PATCH v2] Teach 'git pull' about --rebase

Junio C Hamano wrote:
> Maybe not make this part of git-pull at all?  merge and rebase have
> totally different impact on the resulting history, so perhaps a separate
> command that is a shorthand for "git fetch && git rebase" may help
> unconfuse the users.
At long last, we can revive "git update"!
jdl
Johannes Schindelin· Nov 28, 2007, 22:02 UTC · re: Jon Loeliger · lore

Re: [PATCH v2] Teach 'git pull' about --rebase

Hi,
On Wed, 28 Nov 2007, Jon Loeliger wrote:
Show 8 quoted lines
> Junio C Hamano wrote:
> 
> > Maybe not make this part of git-pull at all?  merge and rebase have
> > totally different impact on the resulting history, so perhaps a separate
> > command that is a shorthand for "git fetch && git rebase" may help
> > unconfuse the users.
> 
> At long last, we can revive "git update"!
No, we cannot.  By now, too many aliases are called "update".

Ciao, Dscho

Björn Steinbrink· Dec 1, 2007, 20:37 UTC · re: Junio C Hamano · lore

Re: [PATCH v2] Teach 'git pull' about --rebase

On 2007.11.28 13:55:39 -0800, Junio C Hamano wrote:
Show 20 quoted lines
> "Lars Hjemli" <hjemli@gmail.com> writes:
> 
> > On 11/28/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >> On Wed, 28 Nov 2007, Steven Grimm wrote:
> >> > I wonder if this shouldn't be branch.<name>.pulltype or something like
> >> > that, so we can represent more than just "rebase or not." Values could
> >> > be "rebase", "merge" (the default) and maybe even "manual" to specify
> >> > that git-pull should neither merge nor rebase a particular branch even
> >> > if it matches a wildcard refspec.
> >>
> >> I am not convinced that this is a good thing... We already have
> >> branch.<name>.mergeOptions for proper merges, and I want to make clear
> >> that this is about rebase, and not about merge.
> >
> > Maybe branch.<name>.pullOptions ?
> 
> Maybe not make this part of git-pull at all?  merge and rebase have
> totally different impact on the resulting history, so perhaps a separate
> command that is a shorthand for "git fetch && git rebase" may help
> unconfuse the users.

Hm, why not tackle the whole thing the other way around? IMHO the primary action is the merge/rebase, not the fetch. So choosing which action you want in addition to the fetch seems a bit backwards. git-svn already includes a fetch from svn in its rebase operation, which is really handy, because you rebase quite often with that beast.

And it's likely that you want to merge with/rebase against the latest available remote commit all the time anyway and on the few(?) occassions where you have no connectivity, but already fetched some remote stuff which you want to incorporate into your local branches now, it's hopefully bearable to pass --no-fetch.

So how about adding --fetch/--no-fetch (maybe with a configurable default?) to git-merge/git-rebase and deprecate git-pull over time?

Björn
Karl Hasselström· Dec 3, 2007, 13:10 UTC · re: Björn Steinbrink · lore

Re: [PATCH v2] Teach 'git pull' about --rebase

On 2007-12-01 21:37:59 +0100, Björn Steinbrink wrote:
> So how about adding --fetch/--no-fetch (maybe with a configurable
> default?) to git-merge/git-rebase and deprecate git-pull over time?

FWIW, I like this idea. rebase/merge is the complicated part of the operation, so the UI should focus on that. Updating or not updating the remote-tracking branch that is merged from/rebased on is a simple binary choice, so a flag is perfect.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle
Jeff King· Oct 26, 2007, 11:43 UTC · re: Johannes Schindelin · lore

Re: [PATCH] Teach 'git pull' the '--rebase' option

On Fri, Oct 26, 2007 at 12:10:08AM +0100, Johannes Schindelin wrote:
Show 9 quoted lines
> Fair enough.
> 
> How about this in the man page:
> 
> \--rebase::
> 	Instead of a merge, perform a rebase after fetching.
> 	*NOTE:* Never do this on branches you plan to publish!  This
> 	command will _destroy_ history, and is thus only suitable for
> 	topic branches to be submitted to another committer.

Reasonable, although perhaps it should mention what I suspect might be a common workflow for this feature: CVS emulation. I.e., there is a central repo, which is the only thing considered "published". Developers make commits in their local repo, and then rebase their changes onto the HEAD before pushing. The only difference from CVS is that you don't actually get to commit in CVS, you have to do the rebase with your working tree. :)

I'm imagining a "pull.rebase = 1" config option, and handing this out to developers accustomed to CVS.

-Peff
Jeff King· Oct 26, 2007, 11:45 UTC · re: Jeff King · lore

Re: [PATCH] Teach 'git pull' the '--rebase' option

On Fri, Oct 26, 2007 at 07:43:32AM -0400, Jeff King wrote:
Show 7 quoted lines
> Reasonable, although perhaps it should mention what I suspect might be a
> common workflow for this feature: CVS emulation. I.e., there is a
> central repo, which is the only thing considered "published". Developers
> make commits in their local repo, and then rebase their changes onto the
> HEAD before pushing. The only difference from CVS is that you don't
> actually get to commit in CVS, you have to do the rebase with your
> working tree. :)

Actually, I think I've just restated Junio's comment somewhat, so the change you made in response to him is an improvement. Sorry for the noise.

-Peff

← back to recent threads