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.
Jay Soffian [off-list ref] 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/
On Wed, Mar 2, 2011 at 2:30 AM, Stefan Haller [off-list ref] wrote:
Jay Soffian [off-list ref] wrote:
quoted
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.
quoted
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.