git hub pull new should set tracking branch

[nomeata]

My workflow is

• git switch master && git pull
• git switch -c my_new_branch (or git branch -m my_new_branch)
• git hub pull new

at this point, git hub creates a new branch fork/my_new_branch. But it does not set it as the tracking branch (i.e. git push -u fork my_new_branch), which means I can’t just update the branch with git push, and I always have to run git push -u fork HEAD.

I wonder if git hub could not do that automatically (at least if no other tracking branch is present).

[leandro-lucarella-sociomantic]

It is definitely doable.

[nomeata]

Is it also worth doing? :-)

I am a bit surprised that nobody else seems to be asking for this – wouldn’t you normally want this behaviour, so that git push after creating the PR will update the PR (instead of trying to push to master, which in the best case fails and the worst case is unintended.)

[llucax]

This should not happen if you have a "triangular workflow" set up (the default in the tool for quite some time now), as all pushes should go to your fork by default (git config remote.pushDefault).

Also, so far we've been driving the configuration in the opposite direction (except for the setup command, which clearly set things up). The tool will look at your config to figure out how to behave. Right now the tracking branch is even expected to point to the upstream repo, not your fork, assuming you'll use git pull to update your pull request with the current base branch changes, as it is used to infer the base branch for new pull requests.

One solution to your problem would be changing your workflow ( 😬 ) and do this instead:

git switch master && git pull
git switch -tc my_new_branch

(note the extra -t). I think it should set the tracking branch as you want it.

I don't have a much better answer for now, all this stuff is very workflow-dependent and different people have different workflows.

One thing we could do to support more workflows and would be a low-hanging fruit is to add an option to make git-hub pull new set the tracking branch.

[nomeata]

Thanks, I’ll look up what git switch -t does, and try with it. Athough it seems it makes make the local master branch the tracking branch of my_new_branch. But maybe together with remote.pushDefault it does the right thing, I’ll experiment, thanks!

(I don't fully understand why it matters whether hub.upstream and hub.forkrepo is the same repository or not; PRs and tracking data is between branches, isn’t it, so I would expect the recommended “triangular” setup to work even if “upstream” and “fork” repositories happen to be the same.)

[llucax]

I don't fully understand why it matters whether hub.upstream and hub.forkrepo is the same repository or not

Where exactly? I don't understand the context of this, because it shouldn't matter (at least in theory, in particular #293 should improve on some cases where maybe it was assumed that they are different).

PRs and tracking data is between branches

Branches and repos, you can see it as a ip:port.

I would expect the recommended “triangular” setup to work even if “upstream” and “fork” repositories happen to be the same

I think the triangular setup should but it makes no sense because there is no "triangle". In this case the triangle is in regards to repos, and it basically only means setting remote.pushdefault to hub.forkremote to git-hub, that's all. If forkremote is the same as upstreamremote, the is basically a NOP (just to clarify, *remote are the names of your git remotes, and it is used for all git commands, while upstream and forkrepo are GitHub repositories, and it's used for the GitHub API calls).

[nomeata]

Where exactly?

It seems to matter for what you call the “triangle”?

I think I am clearly confused, but I’ll stop asking questions; I am still a very happy regular user of git hub, even if I may have a preferred workflow that doesn’t quite match the intended one.

[llucax]

Well, I'm happy to improve it to support more workflows where it makes sense. If the changes are small I might even implement it myself (but accept PRs for all sort of changes).

[llucax]

BTW, it might make more sense to move the discussion to the new Q&A Discussions section, you are welcome to ask whatever you want there.

[llucax]

I'm going to clean up the issue a bit hiding some comments to keep it more readable.