Tao Klerks <tao@xxxxxxxxxx> writes: >> However, I >> wonder how users for whom this may be useful are going to discover this >> option? I don't expect that such users are going to be watching Git's >> release notes looking for new features such as this, or carefully >> reading documentation changes. > > Honestly, I was being a bit selfish here - I effectively control the > gitconfig of "my" users, so I was planning on enabling this by default > and letting it "settle in" in git at large, eventually proposing to > change the default. I am afraid that it is double disservice to your users. Once they graduate your organization, they notice that their Git does not work as they expect and puzzled. > ... > To choose either option permanently, see push.default in 'git help config'. > --- > > I would propose to add one sentence at the end along the lines of: > --- > To instead avoid automatically configuring upstream branches when > their name doesn't match the local branch, see option 'simple' of > branch.autosetupmerge in 'git help config'. > --- > > Does that make sense to you? Two questions. - If a user follows the push.default advice, does it have any advantage to set branch.autosetupmerge=simple at all? - If a user follows the branch.autosetupmerge=simple advice, what happens their "git push" on a branch that the .merge is not set due to this configuration? Shouldn't they have to set up the push.default for these branches anyway? While it might be a good thing to mention branch.autosetupmerge configuration variable, I am not sure if "To instead avoid" is a good thing to say here. It sounds as if the user can ignore push.default as long as branch.autosetupmerge is taken care of, but I suspect that is not the case. Setting the latter to 'simple' means there are *MORE* branches that do not have .remote/.merge set up, doesn't it? Which in turn means that we are relying more on what push.default is set to, right?
