On Nov 15, 2010, at 3:06 PM, Martin von Zweigbergk wrote:
> On Mon, Nov 15, 2010 at 5:48 PM, Kevin Ballard <kevin@xxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html