[1.8.0] fix branch.autosetupmerge and branch.autosetuprebase

[1.8.0] fix branch.autosetupmerge and branch.autosetuprebase

[Jay Soffian]

It strikes me that branch.autosetupmerge and branch.autosetuprebase
are a bit crufty. So a proposal:

Proposal
========

1. Deprecate branch.autosetupmerge. Right now it's got three choices:
false, true, and always, defaulting to "true"

But I wonder, does anyone use "false" and not set the upstream? And I
think that "always" is a misfeature (I'm qualified to say this, see
9ed36cf). 99% of the time, I think you are doing one of the following:

  $ git branch topic origin/master    # 1
  $ git branch topic master           # 2
  $ git branch topic some_other_topic # 3

In the case of (1), you want origin/master to be configured as the
upstream for topic. In the case of (2), even though you are starting
at master, I'll bet you want the upstream to be origin/master. In the
case of (3), even though you are starting at some_other_topic, I'll
bet you want topic to have the same configured upstream as
some_other_topic.

So, my proposal wrt to branch.autosetupmerge is that we deprecate it
and always do the following:

- When creating a local branch L from remote-tracking branch R, set R
as upstream of L.
- When creating a local branch L1 from other local branch L2, whose
upstream is remote-tracking branch R, set R as upstream of L1.

For the 1% of the time that you really want local branch L2 to be
upstream of L1, specify that explicitly when you create the branch.

2. Deprecate branch.autosetuprebase. Pull's default action shouldn't
be specified when the branch is created. Rather, add a "pull.rebase"
boolean defaulting to false, and which is overridden per-branch by
branch.<name>.rebase.

Migration
=========

Let's first see if the proposal flies because it's good, or whether it
has flies because it stinks. :-)

j.

Re: [1.8.0] fix branch.autosetupmerge and branch.autosetuprebase

[Jay Soffian]

On Mon, Feb 28, 2011 at 6:03 PM, Dustin Sallings <dustin@spy.net> wrote:
>
> On Feb 28, 2011, at 14:37, Jay Soffian wrote:
>
> 2. Deprecate branch.autosetuprebase. Pull's default action shouldn't
> be specified when the branch is created. Rather, add a "pull.rebase"
> boolean defaulting to false, and which is overridden per-branch by
> branch.<name>.rebase.
>
> Do you mean to say ``pull.rebase'' configured to true would do the same
> thing?

Effectively, yes. If a user specifies "pull.rebase true" in their
.gitconfig or repo .git/config, then when they "git pull" while on
branch <name>, pull will rebase, unless branch.<name>.rebase exists
and is set to false.

any branches that don't have an explicit "branch.<name>.rebase = false" will

> If so, I'm fine with killing off branch.autosetuprebase.  The goal is to
> have something I can easily give to other people so that we all work the
> same way.

Understood. I recently have the same goal, but my users have
pre-existing branches that they setup before I told them to "git
config branch.autosetuprebase true". Now they need to go configure
every one of those branches to rebase by default.

It would be nice if I could just tell them "git config --global
pull.rebase true" and have it affect all their repos and branches. :-)

j.

Re: [1.8.0] fix branch.autosetupmerge and branch.autosetuprebase

[Miles Bader]

Jay Soffian <jaysoffian@gmail.com> writes:
> So, my proposal wrt to branch.autosetupmerge is that we deprecate it
> and always do the following:
>
> - When creating a local branch L from remote-tracking branch R, set R
> as upstream of L.
> - When creating a local branch L1 from other local branch L2, whose
> upstream is remote-tracking branch R, set R as upstream of L1.

That would certainly match my usage better...

-miles

-- 
Everywhere is walking distance if you have the time.  -- Steven Wright

Re: [1.8.0] fix branch.autosetupmerge and branch.autosetuprebase

[Stefan Haller]

Jay Soffian <jaysoffian@gmail.com> wrote:

> 99% of the time, I think you are doing one of the following:
> 
>   $ git branch topic origin/master    # 1
>   $ git branch topic master           # 2
>   $ git branch topic some_other_topic # 3
> 
> In the case of (1), you want origin/master to be configured as the
> upstream for topic. In the case of (2), even though you are starting
> at master, I'll bet you want the upstream to be origin/master. In the
> case of (3), even though you are starting at some_other_topic, I'll
> bet you want topic to have the same configured upstream as
> some_other_topic.

Where I work, none of these is true.  I guess these may be true for an
open-source kind of setup, where one developer is working on a branch
and then posts a patch series; however, in a corporate environment with
a central repository and multiple developers collaborating on a topic
branch, it's not.  Our workflow is to branch a topic from master (with
--no-track), push the topic to the central repository, others pull the
topic branch (with autosetuprebase=always) and contribute to it, and
eventually it is merged back to master.  We never want automatic
rebasing onto master for topics.

Which means that we only ever have upstream branches with the same name
as the local branch.  I haven't seen a single exception yet, and I wish
there was a way to set autosetupmerge to "only_if_name_matches" or some
such.

> 2. Deprecate branch.autosetuprebase. Pull's default action shouldn't
> be specified when the branch is created. Rather, add a "pull.rebase"
> boolean defaulting to false, and which is overridden per-branch by
> branch.<name>.rebase.

I like this part of the proposal though.


-- 
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/

Re: [1.8.0] fix branch.autosetupmerge and branch.autosetuprebase

[Jay Soffian]

On Wed, Mar 2, 2011 at 2:30 AM, Stefan Haller <lists@haller-berlin.de> wrote:
> Jay Soffian <jaysoffian@gmail.com> wrote:
>
>> 99% of the time, I think you are doing one of the following:
>>
>>   $ git branch topic origin/master    # 1
>>   $ git branch topic master           # 2
>>   $ git branch topic some_other_topic # 3
>>
>> In the case of (1), you want origin/master to be configured as the
>> upstream for topic. In the case of (2), even though you are starting
>> at master, I'll bet you want the upstream to be origin/master. In the
>> case of (3), even though you are starting at some_other_topic, I'll
>> bet you want topic to have the same configured upstream as
>> some_other_topic.
>
> Where I work, none of these is true.  I guess these may be true for an
> open-source kind of setup, where one developer is working on a branch
> and then posts a patch series; however, in a corporate environment with
> a central repository and multiple developers collaborating on a topic
> branch, it's not.  Our workflow is to branch a topic from master (with
> --no-track), push the topic to the central repository

The person who creates topic from master would do the following:

  $ git branch topic origin/master
  $ git push --set-upstream origin topic

Creating topic would initially set its upstream to origin/master.
Specifying "--set-upstream" to push would reset topic's upstream from
origin/master to origin/topic.

Or they could create the topic remotely this way:

  $ git push origin origin/master:refs/heads/topic

> others pull the topic branch (with autosetuprebase=always)

So they'd do something like this:

  $ git fetch
  $ git checkout -b topic origin/topic

which would make origin/topic the upstream of topic, which I think is
exactly what you want.

> and contribute to it, and
> eventually it is merged back to master.  We never want automatic
> rebasing onto master for topics.
>
> Which means that we only ever have upstream branches with the same name
> as the local branch.  I haven't seen a single exception yet, and I wish
> there was a way to set autosetupmerge to "only_if_name_matches" or some
> such.

I don't think my proposal makes your workflow more difficult.

>> 2. Deprecate branch.autosetuprebase. Pull's default action shouldn't
>> be specified when the branch is created. Rather, add a "pull.rebase"
>> boolean defaulting to false, and which is overridden per-branch by
>> branch.<name>.rebase.
>
> I like this part of the proposal though.

Thank you for the feedback.

j.