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. -- 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