[RFC] checkout --rebase

[RFC] checkout --rebase

[Ramkumar Ramachandra]

Hi,

I'm often work on small topic branches, and find myself doing this quite often:

  # on branch master
  $ git checkout um-build
  $ git rebase master

This is horribly inefficient; the first operation takes a _really_
long time to complete, since master updates itself very often and I
have to check out an old worktree.  So, I work around this issue by
doing:

  # on branch master
  $ git checkout -b um-build-2
  $ git cherry-pick ..um-build
  $ git branch -M um-build

... and I scripted it.  Perhaps we should get this functionality in
core, as `git checkout --rebase` (or something)?

Thanks.

Re: [RFC] checkout --rebase

[Sebastian Staudt]

Isn't this what you want?

 $ git rebase master um-build


2013/7/19 Ramkumar Ramachandra <artagnon@gmail.com>:
> Hi,
>
> I'm often work on small topic branches, and find myself doing this quite often:
>
>   # on branch master
>   $ git checkout um-build
>   $ git rebase master
>
> This is horribly inefficient; the first operation takes a _really_
> long time to complete, since master updates itself very often and I
> have to check out an old worktree.  So, I work around this issue by
> doing:
>
>   # on branch master
>   $ git checkout -b um-build-2
>   $ git cherry-pick ..um-build
>   $ git branch -M um-build
>
> ... and I scripted it.  Perhaps we should get this functionality in
> core, as `git checkout --rebase` (or something)?
>
> Thanks.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] checkout --rebase

[Ramkumar Ramachandra]

Sebastian Staudt wrote:
> Isn't this what you want?
>
>  $ git rebase master um-build

Ha, yes.  Sorry about the stupidity.

Re: [RFC] checkout --rebase

[Ramkumar Ramachandra]

Ramkumar Ramachandra wrote:
> Sebastian Staudt wrote:
>> Isn't this what you want?
>>
>>  $ git rebase master um-build
>
> Ha, yes.  Sorry about the stupidity.

Hm, I'm not entirely sure how to optimize the codepath to eliminate
the checkout.  It seems to be absolutely necessary atleast in the -i
codepath.

Let's inspect when $switch_to is set:

	# Is it "rebase other $branchname" or "rebase other $commit"?
	branch_name="$1"
	switch_to="$1"

$revisions seems to be set correctly, and rebase--am does a
move_to_original_branch as the last step.  So, I wonder if this will
work:

diff --git a/git-rebase.sh b/git-rebase.sh
index 0039ecf..7405d9a 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -542,9 +542,15 @@ then
 	if test -z "$force_rebase"
 	then
 		# Lazily switch to the target branch if needed...
-		test -z "$switch_to" ||
-		GIT_REFLOG_ACTION="$GIT_REFLOG_ACTION: checkout $switch_to" \
-			git checkout "$switch_to" --
+		if ! test -z "$switch_to"; then
+			if "$type" = am; then
+				GIT_REFLOG_ACTION="$GIT_REFLOG_ACTION: checkout -b $switch_to-2" \
+					git checkout -b "$switch_to-2" --
+			else
+				GIT_REFLOG_ACTION="$GIT_REFLOG_ACTION: checkout $switch_to" \
+					git checkout "$switch_to" --
+			fi
+		fi
 		say "$(eval_gettext "Current branch \$branch_name is up to date.")"
 		finish_rebase
 		exit 0

(ofcourse, we still need a mechanism to remove this temporary
$switch_to-2 branch)

What about rebase--merge?  Can we eliminate the checkout then?

Re: [RFC] checkout --rebase

[Ramkumar Ramachandra]

Ramkumar Ramachandra wrote:
> diff --git a/git-rebase.sh b/git-rebase.sh
> index 0039ecf..7405d9a 100755
> --- a/git-rebase.sh
> +++ b/git-rebase.sh

Er, sorry.  I think it suffices to check that $branch_name equals
HEAD, for this optimization.

Re: [RFC] checkout --rebase

[Ramkumar Ramachandra]

Damn it: checkout doesn't get executed at all because the $mb = $onto
condition fails; I was looking in the wrong place.  It's format-patch
and am that are slowing things down terribly.  Has anyone looked into
stripping out the dependency?  Why is cherry-pick deficient?

My current workaround is to use the faster `--keep-empty` codepath,
but it doesn't persist state on conflict.  Isn't this an undocumented
fact (aka. bug)?

Thanks.