On Mon, Apr 18, 2022 at 8:15 PM Josh Steadmon <steadmon@xxxxxxxxxx> wrote: > > > I think this is a good solution for relatively inexperienced users, and > I don't see any issues with the implementation or tests. Yay, thanks for the feedback! > 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 understand/agree that this is a little naive - if no-one has reason to try the new behavior, very little information as to its usefulness/appropriateness is likely to emerge, and it will never be an obviously good idea to change the default. > > In the discussion on v3 of this series, you mentioned you were thinking > about adding an advice setting to point users here; is there a reason > why that didn't make it into v4? The advice I mentioned I would work on wasn't actually about this new setting/behavior, but rather about the previously existing (and reasonably unrelated) "not tracking: ambiguous information for ref" error, which I found to be unreasonably cryptic. I submitted that advice change as https://lore.kernel.org/git/pull.1183.v7.git.1648793113943.gitgitgadget@xxxxxxxxx/, and it's gone out in a recent release. > It seems appropriate to me to add one, > perhaps at the point where a user with "autosetupmerge=true" would run > into a failure when trying to push? Having thought about this a bit, I agree. On the one hand I'm a little nervous about adding this kind of public behavior change as I would imagine it's more likely to encounter resistance here, on the other hand I do think it will make the changes themselves much more useful. Also, this patchset hasn't moved in a while, so "holding it up" with new changes may not be a significant concern. the current advice looks something like: --- fatal: The upstream branch of your current branch does not match the name of your current branch. To push to the upstream branch on the remote, use git push origin HEAD:master To push to the branch of the same name on the remote, use git push origin HEAD 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?
