Can I re-enable force pushing, or should I change my workflow?

[jakubledl]

When developing on a branch feature-asdf, I'm used to having the upstream of the branch set to origin/main and have push.default set to current. This means that whenever someone else merges something to origin/main, I immediately see it as ↑m↓n, I can pull and rebase onto origin/main with a simple p and I could push the rebased branch with just P and Enter to confirm the force push.

After upgrading to 0.41.0, #3387 of course broke this workflow, since now it's impossible to force push the branch after the rebase. Is there a way I can get the old behavior back, or should I perhaps do something else entirely? I switched to lazygit from Magit when I stopped using Emacs a few months ago, so it's possible I'm just trying to recreate something that I'm used to and that lazygit has a different/better way to do.

[stefanhaller]

Sorry for breaking your workflow. This is very interesting, I hadn't expected people to work this way. You seem to find it more important to see the divergence from origin/main than to see the divergence from your own upstream branch, which I guess makes sense if you are the only one working on your branch (and you know you only push to it from one machine).

I'm a little unsure what to do here. While I see how your workflow is convenient, it still feels very weird to me, and I'm not sure how hard we should try to support it. Happy to discuss this more though.

That said, I have always missed an easy way to see the divergence of my branch from origin/main; both a simple ↑2↓3 overview, and the more detailed version similar to what you see against your upstream using u enter. I'd be interested in discussing ways to make this information easily accessible somehow, I don't have great ideas myself. Would that be enough to get you to change your workflow to the "normal" one? I do realize that pressing p to rebase onto main would still be missing.

[jakubledl]

Hi @stefanhaller,

many thanks for reply and sorry for my delayed response 🙂 It’s exactly as you describe – I work mostly in a team where everyone is pushing their work into their branches on origin and those then get merged into origin/main. Merges happen frequently, so it’s valuable to see how far behind origin/main your branch is (e.g. to remind you to update your branch now rather than face a ton of merge conflicts later). On the other pretty much the only time two people are going to push into the same branch is during pair-programming sessions, so I’m virtually always sure that I can just wipe anything on the remote branch and replace it with whatever I have on the local branch (and I pretty much never need to pull from the remote branch).

I absolutely understand that it’s a nonstandard workflow and I plan to continue use lazygit even without support for it, it’s a great tool whose benefits for me definitely outweigh the current slight inconvenience 🙂

That said, regarding your last paragraph, as a former user of Magit, I find it’s way of dealing with this really quite convenient. When you check out <name>, it basically let’s you work with both with branch.<name>.pushRemote and branch.<name>.merge. It displays divergence information for both (I think). When you push, it lets you pick whether to push to the push remote (the more convenient key), the merge branch or elsewhere. The same thing works when pulling, with the more convenient key assigned to pulling from the merge branch, I think. When the branch’s push remote or merge branch is unset, it let’s you “set and pull/push” instead. I’ll attach some screenshots later when I’m at my computer.

Perhaps something along those lines might be adapted to work with lazygit and I’d be happy to discuss this further. If there eventually is an idea that you guys might want to include, I’ll be happy to take a shot at implementing it 🙂

[linsui]

I work on a repo that fast-forward only merge is enabled. So I need to rebase and force-push the branch before merging. Force push is used very frequently in my workflow. Can I override the P keybinding to mimic the old behavior?

[stefanhaller]

@linsui Sorry for the late response. Is your setup similar to Jakub's, where you pull from a different branch than you push to? If not, you'll have to explain more what the problem is, because I don't see how being restricted to fast-forward-only merges is related.

@jakubledl I'm curious what your current work-around is. Did you change your workflow, or are you using a custom command to force-push, or something else? (I hope you didn't stop using lazygit because of this. 😄)

I made a quick proof-of-concept draft PR (#3528) with a change that should support your workflow correctly, so pressing shift-P should prompt you to force-push in the appropriate cases. Would be cool if you could try it out.

[linsui]

You are correct. I didn't notice that --force-with-lease is passed by default and in fact the push fails because this problem. https://stackoverflow.com/questions/56191415/why-is-git-push-force-with-lease-failing-with-rejected-stale-info-even

[stefanhaller]

Did you have the problem with a stale remote tracking branch that was mentioned in the stackoverflow answers, or was it some other reason why it didn't work? Usually, --force-with-lease should work fine in lazygit, triangular workflow or not.

[linsui]

I thought my push sometimes fails due to the stale remote tracking branch issue. I usually working with the same local branch and the remote branch is deleted automatically when my MR is merged. So lazygit can't fetch the remote branch. I guess so...

[stefanhaller]

I see. In that case I recommend to do git config --global fetch.prune true, so that remote branches are deleted automatically when you fetch (you'll see "upstream gone" in lazygit), so next time you push it will ask you to create the upstream branch again.

All of that seems unrelated to this issue though.

[linsui]

Good idea, thanks for your help! Yep, I thought this is an unrelated issue.

[jakubledl]

@stefanhaller So currently, I don't really have a workaround 🙂 I have the local feature branch's upstream set to the remote feature branch and I use the local main to see whether there are updates; if I see main ↓3, I checkout main, pull, checkout the feature branch and rebase it onto local main. Since I usually work on just a single feature branch, this works, although it is a bit less convenient.

Thanks for the draft PR, I'll be happy to give it a try in the next few days! I'll also look into custom commands, since that's a topic I haven't really explored yet.

[mark2185]

@jakubledl you don't have to checkout a branch to pull it, you can just fast forward it with f.

[jakubledl]

@mark2185 Thanks for the suggestion, that's definitely quicker! On the other hand, if I checkout main and pull, I automatically get the one-line log overview of what's new in the Commits window (I find that useful in projects where merges happen often and a single workday may bring something like 15 new merges into main).