Kaartic Sivaraam [off-list ref] writes:
1. "git rebase <upstream> <remote_branch>" does nothing
Not limited to "rebase", you do not muck with remote-tracking branch
in your local repository, so it would be a bug if the above updated
where the remote-tracking branch points at.
The form of "git rebase" with one extra argument (i.e. not rebasing
the history that leads to the current checkout) is mere shorthand of
checking that extra thing out before doing the rebase, i.e.
$ git rebase origin/next origin/maint
first checks out origin/maint (you'd get on a detached HEAD) and
rebase the history leading to the detached HEAD on top of
origin/next. If it fast-forwards (and it should if you are talking
about 'maint' and 'next' I publish), you'll end up sitting on a
detached HEAD that points at origin/next.
There is nothing to see here.
2. It's possible to do "git rebase <upstream> <commit>"
Again, that's designed behaviour you can trigger by giving <commit>
(not <branch>). Very handy when you do not trust your upstream or
yourself's ability to resolve potential conflicts as a trial run
before really committing to perform the rebase, e.g.
$ git rebase origin master^0
On Tue, 2017-11-28 at 11:25 +0900, Junio C Hamano wrote:
Kaartic Sivaraam [off-list ref] writes:
quoted
1. "git rebase <upstream> <remote_branch>" does nothing
Not limited to "rebase", you do not muck with remote-tracking branch
in your local repository, so it would be a bug if the above updated
where the remote-tracking branch points at.
The form of "git rebase" with one extra argument (i.e. not rebasing
the history that leads to the current checkout) is mere shorthand of
checking that extra thing out before doing the rebase, i.e.
$ git rebase origin/next origin/maint
first checks out origin/maint (you'd get on a detached HEAD) and
rebase the history leading to the detached HEAD on top of
origin/next. If it fast-forwards (and it should if you are talking
about 'maint' and 'next' I publish), you'll end up sitting on a
detached HEAD that points at origin/next.
There is nothing to see here.
You're right. It was my mistake. It seems I didn't notice that I was
already on 'origin/next' before I did,
$ git rebase origin/next origin/maint
So (obviously) I thought it did nothing, sorry.
quoted
2. It's possible to do "git rebase <upstream> <commit>"
Again, that's designed behaviour you can trigger by giving <commit>
(not <branch>). Very handy when you do not trust your upstream or
yourself's ability to resolve potential conflicts as a trial run
before really committing to perform the rebase, e.g.
$ git rebase origin master^0
I can't comment about usefulness as I haven't used rebase in this way
but I'm pretty sure that this should be mentioned in the
"Documentation" to help those might be in bare need of syntax like this
to discover it.
Something like the following diff with additional changes to other
places that refer to <branch>,
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 67d48e688..ba4a545bf 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -9,9 +9,9 @@ SYNOPSIS
--------
[verse]
'git rebase' [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>]
- [<upstream> [<branch>]]
+ [<upstream> [<ref>]]
'git rebase' [-i | --interactive] [options] [--exec <cmd>] [--onto <newbase>]
- --root [<branch>]
+ --root [<ref>]
'git rebase' --continue | --skip | --abort | --quit | --edit-todo
DESCRIPTION
If <ref> is the correct substitute <branch>, I could try to send a
patch that fixes this.
--
Kaartic