[1.8.0] fix branch.autosetupmerge and branch.autosetuprebase

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 <jaysoffian@gmail.com> writes:

That would certainly match my usage better...

-miles

Jay Soffian <jaysoffian@gmail.com> wrote:

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.

I like this part of the proposal though.

On Wed, Mar 2, 2011 at 2:30 AM, Stefan Haller <lists@haller-berlin.de> wrote:

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

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.

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

Thank you for the feedback.

j.

On Mon, Feb 28, 2011 at 6:03 PM, Dustin Sallings <dustin@spy.net> wrote:

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

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.