2 ms·
It will overwrite the tree on remote as long as remote hasn't changed since you last fetched it. Like --force, but can help to prevent overwriting other people'
by ok_dad 4y ago
It will overwrite the tree on remote as long as remote hasn't changed since you last fetched it. Like --force, but can help to prevent overwriting other people's changes when they push in between you fetching. It doesn't always work, particularly if you have a tool which continuously fetches remote, like an IDE configured to do so such as VSCode. In that case, you will have fetched the other person's changes, and --force-with-lease will happily blow-away anything on remote that might not be in your tree yet.
- FPGAhacker 4y agoOof, thanks for that warning. So it will blow away changes you haven’t merged (only fetched)? I guess git can’t tell the he difference between “not merged yet” and “don’t want to merge, please destroy”
- erik_seaberg 4y agoThe changes still exist in the repo’s reflog (for 30 days by default), but they might not be reachable from the ref’s new tip commit.
- rawling 4y agoIf you don't want to blow away changes you haven't merged, you shouldn't be doing force at all?
- FPGAhacker 4y agoWell, the article presents a seemingly nice workflow that lets you handle local rebases. I was considering it. However, we use vscode, and I rather like auto fetch. But apparently this workflow would destroy something auto fetched that I might not have even noticed.