* [RFC] rebase: use @{upstream} if no upstream specified
@ 2010-11-12 20:55 Martin von Zweigbergk
2010-11-13 9:51 ` Yann Dirson
2010-11-15 22:48 ` Kevin Ballard
0 siblings, 2 replies; 11+ messages in thread
From: Martin von Zweigbergk @ 2010-11-12 20:55 UTC (permalink / raw)
To: git; +Cc: Martin von Zweigbergk
With 'git pull --rebase', the user can configure the upstream repository
to fetch from and reference to rebase against if none is specified on
the command line.
However, if, instead of 'git pull --rebase', the user were to do 'git
fetch' followed by 'git rebase', the upstream branch would need to be
specified on the command line. This patch teaches 'git rebase' to
default to the same configured upstream ref as 'git pull --rebase'
uses.
'git rebase' currently require at least one argument, so this change does
not cause any ambiguity. Defaulting to @{upstream} will make it possible
to run e.g. 'git rebase -i' without arguments, which is probably a quite
common use case. It also improves the scenario where you have multiple
branches that rebase against a remote-tracking branch, where you
currently have to choose between the extra network delay of 'git pull' or
the awkward keys to enter 'git rebase @{u}'.
---
Another RFC in the same vein as my previous one, namely making
'git fetch+rebase' more similar to 'git pull --rebase'.
Junio, don't apply this patch yet, as I will rebase it on top of the
refactored rebase code once I'm done with that (to make it work with
interactive rebase as well).
However, it should apply cleanly on top of the patches in
http://thread.gmane.org/gmane.comp.version-control.git/160682/, and maybe
even right on top of master.
The obvious extension would be to make @{u} the default for 'git merge'
as well. Any opinions?
I was apparently very lazy with the testing, so I will have to improve on
that before this becomes a "PATCH v1". I will add a test case that checks
that it works when the upstream actually is configured.
Documentation/git-rebase.txt | 6 +++++-
git-rebase.sh | 37 ++++++++++++++++++++++++++-----------
t/t3400-rebase.sh | 4 ++--
3 files changed, 33 insertions(+), 14 deletions(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 1baddd2..42d13a0 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
'git rebase' [-i | --interactive] [options] [--onto <newbase>]
- <upstream> [<branch>]
+ [<upstream>] [<branch>]
'git rebase' [-i | --interactive] [options] --onto <newbase>
--root [<branch>]
@@ -21,6 +21,10 @@ If <branch> is specified, 'git rebase' will perform an automatic
`git checkout <branch>` before doing anything else. Otherwise
it remains on the current branch.
+If <upstream> is not specified, the upstream configured in
+branch.<name>.remote and branch.<name>.merge options will be used; see
+linkgit:git-config[1] for details.
+
All changes made by commits in the current branch but that are not
in <upstream> are saved to a temporary area. This is the same set
of commits that would be shown by `git log <upstream>..HEAD` (or
diff --git a/git-rebase.sh b/git-rebase.sh
index fade99a..7eb1a6e 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -3,7 +3,7 @@
# Copyright (c) 2005 Junio C Hamano.
#
-USAGE='[--interactive | -i] [-v] [--force-rebase | -f] [--no-ff] [--onto <newbase>] (<upstream>|--root) [<branch>] [--quiet | -q]'
+USAGE='[--interactive | -i] [-v] [--force-rebase | -f] [--no-ff] [--onto <newbase>] [<upstream>|--root] [<branch>] [--quiet | -q]'
LONG_USAGE='git-rebase replaces <branch> with a new branch of the
same name. When the --onto option is provided the new branch starts
out with a HEAD equal to <newbase>, otherwise it is equal to <upstream>
@@ -369,13 +369,6 @@ do
done
test $# -gt 2 && usage
-if test $# -eq 0 && test -z "$rebase_root"
-then
- test -d "$merge_dir" -o -d "$apply_dir" || usage
- test -d "$merge_dir" -o -f "$apply_dir"/rebasing &&
- die 'A rebase is in progress, try --continue, --skip or --abort.'
-fi
-
# Make sure we do not have $apply_dir or $merge_dir
if test -z "$do_merge"
then
@@ -416,9 +409,31 @@ esac
if test -z "$rebase_root"
then
- # The upstream head must be given. Make sure it is valid.
- upstream_name="$1"
- shift
+ case "$#" in
+ 0) branch_name=$(git symbolic-ref -q HEAD) &&
+ upstream_name=$(git for-each-ref \
+ --format='%(upstream)' ${branch_name})
+ if test -z $branch_name
+ then
+ die "You are not currently on a branch, so I cannot use any
+'branch.<branchname>.merge' in your configuration file.
+Please specify which upstream branch you want to use on the command
+line and try again (e.g. 'git rebase <upstream branch>').
+See git-rebase(1) for details."
+ elif test -z $upstream_name
+ then
+ die "You asked me to rebase without telling me which branch you
+want to rebase against, and 'branch.${branch_name#refs/heads/}.merge' in
+your configuration file does not tell me, either. Please
+specify which branch you want to use on the command line and
+try again (e.g. 'git rebase <upstream branch>').
+See git-rebase(1) for details."
+ fi
+ ;;
+ *) upstream_name="$1"
+ shift
+ ;;
+ esac
upstream=`git rev-parse --verify "${upstream_name}^0"` ||
die "invalid upstream $upstream_name"
unset root_flag
diff --git a/t/t3400-rebase.sh b/t/t3400-rebase.sh
index b64df31..5b0a29b 100755
--- a/t/t3400-rebase.sh
+++ b/t/t3400-rebase.sh
@@ -161,11 +161,11 @@ rm -f B
test_expect_success 'dump usage when upstream arg is missing' '
git checkout -b usage topic &&
test_must_fail git rebase 2>error1 &&
- grep "[Uu]sage" error1 &&
+ grep "branch.usage.merge" error1 &&
test_must_fail git rebase --abort 2>error2 &&
grep "No rebase in progress" error2 &&
test_must_fail git rebase --onto master 2>error3 &&
- grep "[Uu]sage" error3 &&
+ grep "branch.usage.merge" error3 &&
! grep "can.t shift" error3
'
--
1.7.3.2.167.ga361b
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [RFC] rebase: use @{upstream} if no upstream specified
2010-11-12 20:55 [RFC] rebase: use @{upstream} if no upstream specified Martin von Zweigbergk
@ 2010-11-13 9:51 ` Yann Dirson
2010-11-17 2:29 ` Martin von Zweigbergk
2010-11-15 22:48 ` Kevin Ballard
1 sibling, 1 reply; 11+ messages in thread
From: Yann Dirson @ 2010-11-13 9:51 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git
On Fri, Nov 12, 2010 at 09:55:49PM +0100, Martin von Zweigbergk wrote:
> With 'git pull --rebase', the user can configure the upstream repository
> to fetch from and reference to rebase against if none is specified on
> the command line.
>
> However, if, instead of 'git pull --rebase', the user were to do 'git
> fetch' followed by 'git rebase', the upstream branch would need to be
> specified on the command line. This patch teaches 'git rebase' to
> default to the same configured upstream ref as 'git pull --rebase'
> uses.
It is something I've meant to take a stake at since ages, cool!
Note that the same holds for "merge".
> The obvious extension would be to make @{u} the default for 'git merge'
> as well. Any opinions?
Hell, yes :)
> @@ -21,6 +21,10 @@ If <branch> is specified, 'git rebase' will perform an automatic
> `git checkout <branch>` before doing anything else. Otherwise
> it remains on the current branch.
>
> +If <upstream> is not specified, the upstream configured in
> +branch.<name>.remote and branch.<name>.merge options will be used; see
> +linkgit:git-config[1] for details.
> +
Maybe make explicit that it will abort when no upstream is configured.
> @@ -416,9 +409,31 @@ esac
>
> if test -z "$rebase_root"
> then
> - # The upstream head must be given. Make sure it is valid.
> - upstream_name="$1"
> - shift
> + case "$#" in
> + 0) branch_name=$(git symbolic-ref -q HEAD) &&
> + upstream_name=$(git for-each-ref \
> + --format='%(upstream)' ${branch_name})
> + if test -z $branch_name
> + then
> + die "You are not currently on a branch, so I cannot use any
> +'branch.<branchname>.merge' in your configuration file.
> +Please specify which upstream branch you want to use on the command
> +line and try again (e.g. 'git rebase <upstream branch>').
> +See git-rebase(1) for details."
> + elif test -z $upstream_name
> + then
> + die "You asked me to rebase without telling me which branch you
> +want to rebase against, and 'branch.${branch_name#refs/heads/}.merge' in
> +your configuration file does not tell me, either. Please
> +specify which branch you want to use on the command line and
> +try again (e.g. 'git rebase <upstream branch>').
> +See git-rebase(1) for details."
> + fi
> + ;;
> + *) upstream_name="$1"
> + shift
> + ;;
> + esac
> upstream=`git rev-parse --verify "${upstream_name}^0"` ||
> die "invalid upstream $upstream_name"
> unset root_flag
What about simply checking if "rev-parse @{u}" succeeds, in which case
we can use upstream_name=@{u} ? If it fails, then we can do the work
of finding where the config flaw is (and delegate this to a func).
That would help keep the nominal code path short.
--
Yann
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] rebase: use @{upstream} if no upstream specified
2010-11-12 20:55 [RFC] rebase: use @{upstream} if no upstream specified Martin von Zweigbergk
2010-11-13 9:51 ` Yann Dirson
@ 2010-11-15 22:48 ` Kevin Ballard
2010-11-15 23:06 ` Martin von Zweigbergk
1 sibling, 1 reply; 11+ messages in thread
From: Kevin Ballard @ 2010-11-15 22:48 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git
On Nov 12, 2010, at 12:55 PM, Martin von Zweigbergk wrote:
> With 'git pull --rebase', the user can configure the upstream repository
> to fetch from and reference to rebase against if none is specified on
> the command line.
>
> However, if, instead of 'git pull --rebase', the user were to do 'git
> fetch' followed by 'git rebase', the upstream branch would need to be
> specified on the command line. This patch teaches 'git rebase' to
> default to the same configured upstream ref as 'git pull --rebase'
> uses.
What happens if one were to do `git fetch origin some_other_branch`
followed by `git rebase`?
-Kevin Ballard
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] rebase: use @{upstream} if no upstream specified
2010-11-15 22:48 ` Kevin Ballard
@ 2010-11-15 23:06 ` Martin von Zweigbergk
2010-11-15 23:12 ` Jay Soffian
2010-11-15 23:16 ` Kevin Ballard
0 siblings, 2 replies; 11+ messages in thread
From: Martin von Zweigbergk @ 2010-11-15 23:06 UTC (permalink / raw)
To: Kevin Ballard; +Cc: git
On Mon, Nov 15, 2010 at 5:48 PM, Kevin Ballard <kevin@sb.org> wrote:
> On Nov 12, 2010, at 12:55 PM, Martin von Zweigbergk wrote:
>
>> With 'git pull --rebase', the user can configure the upstream repository
>> to fetch from and reference to rebase against if none is specified on
>> the command line.
>>
>> However, if, instead of 'git pull --rebase', the user were to do 'git
>> fetch' followed by 'git rebase', the upstream branch would need to be
>> specified on the command line. This patch teaches 'git rebase' to
>> default to the same configured upstream ref as 'git pull --rebase'
>> uses.
>
> What happens if one were to do `git fetch origin some_other_branch`
> followed by `git rebase`?
Good question. What would happen with my patch is that you would rebase
against your configured uptream.
The requirement to provide the upstream for 'git rebase', but not for
'git pull' was my inspiration, but maybe I should not mention that it
the commit message. So maybe my motivation is flawed, but ignoring that,
do you think it is sensible to default to '@{upstream}'?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] rebase: use @{upstream} if no upstream specified
2010-11-15 23:06 ` Martin von Zweigbergk
@ 2010-11-15 23:12 ` Jay Soffian
2010-11-15 23:16 ` Kevin Ballard
1 sibling, 0 replies; 11+ messages in thread
From: Jay Soffian @ 2010-11-15 23:12 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: Kevin Ballard, git
On Mon, Nov 15, 2010 at 3:06 PM, Martin von Zweigbergk
<martin.von.zweigbergk@gmail.com> wrote:
> do you think it is sensible to default to '@{upstream}'?
I certainly do.
j.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] rebase: use @{upstream} if no upstream specified
2010-11-15 23:06 ` Martin von Zweigbergk
2010-11-15 23:12 ` Jay Soffian
@ 2010-11-15 23:16 ` Kevin Ballard
1 sibling, 0 replies; 11+ messages in thread
From: Kevin Ballard @ 2010-11-15 23:16 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git
On Nov 15, 2010, at 3:06 PM, Martin von Zweigbergk wrote:
> On Mon, Nov 15, 2010 at 5:48 PM, Kevin Ballard <kevin@sb.org> wrote:
>> On Nov 12, 2010, at 12:55 PM, Martin von Zweigbergk wrote:
>>
>>> With 'git pull --rebase', the user can configure the upstream repository
>>> to fetch from and reference to rebase against if none is specified on
>>> the command line.
>>>
>>> However, if, instead of 'git pull --rebase', the user were to do 'git
>>> fetch' followed by 'git rebase', the upstream branch would need to be
>>> specified on the command line. This patch teaches 'git rebase' to
>>> default to the same configured upstream ref as 'git pull --rebase'
>>> uses.
>>
>> What happens if one were to do `git fetch origin some_other_branch`
>> followed by `git rebase`?
>
> Good question. What would happen with my patch is that you would rebase
> against your configured uptream.
>
> The requirement to provide the upstream for 'git rebase', but not for
> 'git pull' was my inspiration, but maybe I should not mention that it
> the commit message. So maybe my motivation is flawed, but ignoring that,
> do you think it is sensible to default to '@{upstream}'?
I personally am not in favor of providing a default at all, but if we must,
then @{upstream} is a sensible one. I just think suggesting that this allows
you to split up `git pull --rebase` into `git fetch + git rebase` may be
confusing unless you make it clear that this only applies to an invocation
of `git pull --rebase` that names no branches.
-Kevin Ballard
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] rebase: use @{upstream} if no upstream specified
2010-11-13 9:51 ` Yann Dirson
@ 2010-11-17 2:29 ` Martin von Zweigbergk
2010-11-19 21:15 ` Jeff King
0 siblings, 1 reply; 11+ messages in thread
From: Martin von Zweigbergk @ 2010-11-17 2:29 UTC (permalink / raw)
To: Yann Dirson; +Cc: git, Jeff King, Johannes Schindelin, Santi Béjar
On Sat, Nov 13, 2010 at 4:51 AM, Yann Dirson <ydirson@free.fr> wrote:
> On Fri, Nov 12, 2010 at 09:55:49PM +0100, Martin von Zweigbergk wrote:
>
>> @@ -21,6 +21,10 @@ If <branch> is specified, 'git rebase' will perform an automatic
>> `git checkout <branch>` before doing anything else. Otherwise
>> it remains on the current branch.
>>
>> +If <upstream> is not specified, the upstream configured in
>> +branch.<name>.remote and branch.<name>.merge options will be used; see
>> +linkgit:git-config[1] for details.
>> +
>
> Maybe make explicit that it will abort when no upstream is configured.
Will do.
>
>> @@ -416,9 +409,31 @@ esac
>>
>> if test -z "$rebase_root"
>> then
>> - # The upstream head must be given. Make sure it is valid.
>> - upstream_name="$1"
>> - shift
>> + case "$#" in
>> + 0) branch_name=$(git symbolic-ref -q HEAD) &&
>> + upstream_name=$(git for-each-ref \
>> + --format='%(upstream)' ${branch_name})
>> + if test -z $branch_name
>> + then
>> + die "You are not currently on a branch, so I cannot use any
>> +'branch.<branchname>.merge' in your configuration file.
>> +Please specify which upstream branch you want to use on the command
>> +line and try again (e.g. 'git rebase <upstream branch>').
>> +See git-rebase(1) for details."
>> + elif test -z $upstream_name
>> + then
>> + die "You asked me to rebase without telling me which branch you
>> +want to rebase against, and 'branch.${branch_name#refs/heads/}.merge' in
>> +your configuration file does not tell me, either. Please
>> +specify which branch you want to use on the command line and
>> +try again (e.g. 'git rebase <upstream branch>').
>> +See git-rebase(1) for details."
>> + fi
>> + ;;
>> + *) upstream_name="$1"
>> + shift
>> + ;;
>> + esac
>> upstream=`git rev-parse --verify "${upstream_name}^0"` ||
>> die "invalid upstream $upstream_name"
>> unset root_flag
>
> What about simply checking if "rev-parse @{u}" succeeds, in which case
> we can use upstream_name=@{u} ? If it fails, then we can do the work
> of finding where the config flaw is (and delegate this to a func).
> That would help keep the nominal code path short.
Will make sure to find out the error only when needed as you suggest.
I thought I would need the ref name to be able to walk the reflog if my
other propasal would be accepted (see
http://thread.gmane.org/gmane.comp.version-control.git/161381), but it
seems to work with @{u} as well. I just adapted the call from 'git pull'
(git-parse-remote.sh), but I guess I could use 'git rev-parse @{upstream}'
instead. It does seem more natural to me.
Maybe one of the guys on the CC list can advise?
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] rebase: use @{upstream} if no upstream specified
2010-11-17 2:29 ` Martin von Zweigbergk
@ 2010-11-19 21:15 ` Jeff King
2010-11-20 0:26 ` Martin von Zweigbergk
0 siblings, 1 reply; 11+ messages in thread
From: Jeff King @ 2010-11-19 21:15 UTC (permalink / raw)
To: Martin von Zweigbergk
Cc: Yann Dirson, git, Johannes Schindelin, Santi Béjar
On Tue, Nov 16, 2010 at 09:29:46PM -0500, Martin von Zweigbergk wrote:
> > What about simply checking if "rev-parse @{u}" succeeds, in which case
> > we can use upstream_name=@{u} ? If it fails, then we can do the work
> > of finding where the config flaw is (and delegate this to a func).
> > That would help keep the nominal code path short.
>
> Will make sure to find out the error only when needed as you suggest.
>
> I thought I would need the ref name to be able to walk the reflog if my
> other propasal would be accepted (see
> http://thread.gmane.org/gmane.comp.version-control.git/161381), but it
> seems to work with @{u} as well. I just adapted the call from 'git pull'
> (git-parse-remote.sh), but I guess I could use 'git rev-parse @{upstream}'
> instead. It does seem more natural to me.
>
> Maybe one of the guys on the CC list can advise?
I'm not quite sure I understand the question, coming into the middle of
the conversation. If you want to know "can I traverse the reflog of the
upstream with @{u}", the answer is yes. We dereference the ref first
(similarly, foo@{u}@{3.days.ago} looks at the upstream branch's reflog).
If you want the refname, you can also use "git rev-parse
--symbolic-full-name @{u}".
Does that help?
-Peff
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] rebase: use @{upstream} if no upstream specified
2010-11-19 21:15 ` Jeff King
@ 2010-11-20 0:26 ` Martin von Zweigbergk
2010-11-20 4:10 ` Jeff King
0 siblings, 1 reply; 11+ messages in thread
From: Martin von Zweigbergk @ 2010-11-20 0:26 UTC (permalink / raw)
To: Jeff King; +Cc: Yann Dirson, git, Johannes Schindelin, Santi Béjar
On Fri, Nov 19, 2010 at 4:15 PM, Jeff King <peff@peff.net> wrote:
> On Tue, Nov 16, 2010 at 09:29:46PM -0500, Martin von Zweigbergk wrote:
>
>> > What about simply checking if "rev-parse @{u}" succeeds, in which case
>> > we can use upstream_name=@{u} ? If it fails, then we can do the work
>> > of finding where the config flaw is (and delegate this to a func).
>> > That would help keep the nominal code path short.
>>
>> Will make sure to find out the error only when needed as you suggest.
>>
>> I thought I would need the ref name to be able to walk the reflog if my
>> other propasal would be accepted (see
>> http://thread.gmane.org/gmane.comp.version-control.git/161381), but it
>> seems to work with @{u} as well. I just adapted the call from 'git pull'
>> (git-parse-remote.sh), but I guess I could use 'git rev-parse @{upstream}'
>> instead. It does seem more natural to me.
>>
>> Maybe one of the guys on the CC list can advise?
>
> I'm not quite sure I understand the question, coming into the middle of
> the conversation. If you want to know "can I traverse the reflog of the
> upstream with @{u}", the answer is yes. We dereference the ref first
> (similarly, foo@{u}@{3.days.ago} looks at the upstream branch's reflog).
> If you want the refname, you can also use "git rev-parse
> --symbolic-full-name @{u}".
>
> Does that help?
Yes, I did try that and I noticed that it worked, but it helps to know
that it is not just by accident. I realize I was not very clear, but
what I really was wondering if there is any advantage to using
"git for-each-ref --format='%(upstream)' ${branch_name}" (as used by
git pull) as compared to "git rev-parse @{upstream}" as suggested by
Yann. ($branch_name in this case would be the current branch.)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] rebase: use @{upstream} if no upstream specified
2010-11-20 0:26 ` Martin von Zweigbergk
@ 2010-11-20 4:10 ` Jeff King
2010-11-20 13:14 ` Martin von Zweigbergk
0 siblings, 1 reply; 11+ messages in thread
From: Jeff King @ 2010-11-20 4:10 UTC (permalink / raw)
To: Martin von Zweigbergk
Cc: Yann Dirson, git, Johannes Schindelin, Santi Béjar
On Fri, Nov 19, 2010 at 07:26:57PM -0500, Martin von Zweigbergk wrote:
> Yes, I did try that and I noticed that it worked, but it helps to know
> that it is not just by accident. I realize I was not very clear, but
> what I really was wondering if there is any advantage to using
> "git for-each-ref --format='%(upstream)' ${branch_name}" (as used by
> git pull) as compared to "git rev-parse @{upstream}" as suggested by
> Yann. ($branch_name in this case would be the current branch.)
No, I don't think there is a reason to prefer one over the other these
days. When the instance in git-parse-remote was written (e9460a6,
2009-06-12) @{upstream} did not yet exist (it came in 28fb843,
2009-09-10). So for-each-ref was the only way to get the informationa
I would use whichever one seems clearer in your context.
-Peff
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [RFC] rebase: use @{upstream} if no upstream specified
2010-11-20 4:10 ` Jeff King
@ 2010-11-20 13:14 ` Martin von Zweigbergk
0 siblings, 0 replies; 11+ messages in thread
From: Martin von Zweigbergk @ 2010-11-20 13:14 UTC (permalink / raw)
To: Jeff King; +Cc: Yann Dirson, git, Johannes Schindelin, Santi Béjar
On Fri, Nov 19, 2010 at 11:10 PM, Jeff King <peff@peff.net> wrote:
> On Fri, Nov 19, 2010 at 07:26:57PM -0500, Martin von Zweigbergk wrote:
>
>> Yes, I did try that and I noticed that it worked, but it helps to know
>> that it is not just by accident. I realize I was not very clear, but
>> what I really was wondering if there is any advantage to using
>> "git for-each-ref --format='%(upstream)' ${branch_name}" (as used by
>> git pull) as compared to "git rev-parse @{upstream}" as suggested by
>> Yann. ($branch_name in this case would be the current branch.)
>
> No, I don't think there is a reason to prefer one over the other these
> days. When the instance in git-parse-remote was written (e9460a6,
> 2009-06-12) @{upstream} did not yet exist (it came in 28fb843,
> 2009-09-10). So for-each-ref was the only way to get the informationa
Ah, I see. Now it is all clear. I should not have assumed that
'%(upstream)' and '@{upstream}' were introduced at the same time.
Thanks.
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2010-11-20 13:14 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-11-12 20:55 [RFC] rebase: use @{upstream} if no upstream specified Martin von Zweigbergk
2010-11-13 9:51 ` Yann Dirson
2010-11-17 2:29 ` Martin von Zweigbergk
2010-11-19 21:15 ` Jeff King
2010-11-20 0:26 ` Martin von Zweigbergk
2010-11-20 4:10 ` Jeff King
2010-11-20 13:14 ` Martin von Zweigbergk
2010-11-15 22:48 ` Kevin Ballard
2010-11-15 23:06 ` Martin von Zweigbergk
2010-11-15 23:12 ` Jay Soffian
2010-11-15 23:16 ` Kevin Ballard
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).