Stop modifying the remote tracking branch for a branch

[Gelio]

Hey! I've just started using this tool to simplify working with stacked branches and it looks promising.

One thing that is annoying me is that upon rebasing a stack, the remote tracking branches are changed and point to the remote branches under the same name. I have been setting my remote tracking branches to the parent branch to quickly see the status in git log and in https://github.com/tpope/vim-fugitive.

Do you think we could avoid modifying the remote tracking branch to a given branch if it's already set?

[epage]

Trying to think through what is causing this. My two best guesses:

• You passed --push. When we push, we use --set-upstream.
• Branches were deleted and re-added as they get moved but we don't preserve the upstream, so you are getting whatever it defaults to

In general, we assume the remote tracking branch is set to the branch the user will push:

• As a convenience for users pushing directly
• As a safety measure so users don't accidentally push to a shared branch

Git already pushes users this way by encouraging setting the remote when they do a git push

Since I've not set my remote tracking branch like you (and haven't adopted fugutive), I would be interested in hearing what it gives users to do so. That can help weigh any decisions made.

Moving forward, out options are

• Always set upstream as the branch we push to
• Always set upstream to the branch we pull from
• Make the workflow configurable
• Always initialize branches to where the upstream is the branch we push to but respect it if the user changes it (ie only pass --set-upstream on first push, preserve it through rebasing of branches)

Any other options you can think of?

[Gelio]

You passed --push. When we push, we use --set-upstream.

I think that was the root of my problem.

Since I've not set my remote tracking branch like you (and haven't adopted fugutive), I would be interested in hearing what it gives users to do so. That can help weigh any decisions made.

In the status view, vim-fugitive show commits from a couple of rev ranges (comments assume push.default set to simple - the default value):

• HEAD..@{push} - unpushed to the remote
• @{push}..HEAD - unpulled from remote (matters when the remote branch was rebased e.g. via the UI)
• @{upstream}..HEAD - same as @{push}..HEAD in this case, because we push to the remote tracking brnach

If your push is the same as your upstream (remote tracking branch), as is the case by default, this view is not too useful to see the commits between the current branch and the parent branch in the stack, because neither push nor upstream point to the parent branch.

I mentioned that in tpope/vim-fugitive#1700 (comment) and @tpope recommended setting push.default to current so my @{push} points to the branch with the same name as the current one, and setting my upstream tracking branch to the parent branch. This way the rev ranges are:

• HEAD..@{push} - commits made on top of the parent branch
• @{push}..HEAD - unpulled from the parent branch, in case it changed e.g. because it was rebased. Usually empty
• @{upstream}..HEAD - unpulled from the remote branch, in case it changed e.g. via a rebase

The first one is the most useful.

Moreover, in the CLI (when using vanilla git, without any tools like git stack) git status displays the number of commits made on top of the parent branch:

17:53 $ git status
On branch smart-csv-preview-submit-button-CU-1zg1bv6
Your branch is ahead of 'origin/improve-repository-name-form-integration-CU-24ape6r' by 1 commit.
  (use "git push" to publish your local commits)

nothing to commit, working tree clean

and you can also easily get a rev range starting from the parent branch without having to check what the parent branch is:

$ git log @{upstream}..

I've been using git config push.default current for a year and I have generally been satisfied.

I don't remember well, but this could also make git rebase work better without specifying the target branch/commit, because the upstream that it uses by default is the parent branch.

Anyway, I'm not trying to convert anyone, just explaining my setup and the benefits.

Any other options you can think of?

The ideal behavior for me would be to detect the value of git config push.default. If it is set to current then always set the remote tracking branch to the parent branch. If it is something else (or the default value), then use the existing behavior. That could be another option in the list of options you listed

As for the options you've listed, personally, I believe the last one makes the most sense at the moment. One minor change I would do is to only set the upstream on the first push if it is not specified, so it does not override my remote tracking branch on the first push too 😄 I usually set my upstream tracking branch to the parent branch the moment I create a new branch, so I have it set the moment I push, which would let git stack --push detect I have it set and leave it unmodified

[epage]

v0.5.6 is released and it should not override an existing configured upstream.

Things are still a bit fuzzy for me on simple vs current and their impact, so I'm wanting to be cautious about making a change relying on it, for now, but feel free to create an issue for us to continue the conversation so we don't lose track of this.

[Gelio]

Awesome, thank you! I will try it out during the next couple of days and report back. I really appreciate you updating the tool in such a short time. Looking at the changes, it looks promising

[Gelio]

I've tried git stack --push and it seems to preserve the upstream tracking branches correctly. Not sure if there is a way to close/resolve the discussion, but IMO this behavior is good enough to consider my problem solved. Thanks once again!