Jay Soffian <jaysoffian@xxxxxxxxx> 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/ -- 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