Add "catch-up" sync option to Git extension

[SetTrend]

The following process is, supposedly, performed regularly:

1. Clone a public repository.
2. Add upstream remote to local repository.
3. Checkout master branch.
4. Create a feature branch.
5. Commit changes.
6. Upload changes to remote repository ("sync" in Visual Studio code).
7. Create merge/pull request.

8. ... wait days/weeks/months ...
9. Fetch latest master branch from public (upstream) repository.
10. Merge upstream master branch into local master branch.
11. Rebase (current) feature branch from local master branch.
12. Upload changes to remote repository ("sync" in Visual Studio code).

8. ... wait days/weeks/months ...
9. Fetch latest master branch from public (upstream) repository.
10. Merge upstream master branch into local master branch.
11. Rebase (current) feature branch from local master branch.
12. Upload changes to remote repository ("sync" in Visual Studio code).

...

It is so much ado and it's so error prone when typing all these commands into the VS Code terminal. I regularly find myself deleting and manually re-creating my branches because my branch history gets bloated with foreign commits from the upstream's master branch plus redundant merge commits.

Suggestion

Wouldn't it make sense to add a context menu item to the Git panel, located at the sync label, automating steps 9 to 12, performing all the intricacies automatically, keeping the history intact and tidy? (Including the omission of redundant/empty merge commits.)

Additional Options

There should be an option to have the above suggested feature become the default "sync" behaviour of the VS Code Git panel.

Moreover, the suggested sync context menu should provide a new sub menu item, providing all three sync methods, so the user may interactively choose a different sync method:

| ------------------- |
| Sync with remote  > |
| --------- | Merge         |
            | Rebase        |
            | Catch-up      |
            | ------------- |

[vscodebot]

(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Git: Preserve open files list when switching branches (#35307)
• Git: Checkout to a tracked local branch instead when trying to checkout to a remote branch (#61149)
• Git: Support to create local branch from specific remote branch (#55732)
• branch change on disk not synced in VSC (#62130)
• Suggestion: Create git branch action in checkout dropdown after typing in new branch name (#60895)

[joaomoreno]

This seems to be a very very specific workflow.

Rebase (current) feature branch from local master branch.

Why exactly do you do this? Why wouldn't you simply merge origin/master into your feature branch, the same way you seem to do into master?

And, can you not automate this with git aliases?

[SetTrend]

Are you referring to git merge in favour of git rebase? I want to see my commits at the end of the list of all foreign commits, not somewhere in between. As long as my merge/pull requests haven't been reviewed/pulled I don't want to lose track on my changes.

The main issue I currently see, however, with the current VS Code syncing is that it's bloating my merge/pull request commit history with foreign commits after having merged my origin/master with upstream/master and then merging/rebasing my feature branch with my updated origin/master branch. When I finally sync the updated feature branch, the commit list in GitHub/GitLab is a mess (see StackOverflow issue referenced above).

I'm working on many different (virtual) machines and many different projects. Aliases wouldn't be of any help to me, I'm afraid. I would tend to forget my aliases over time.

Moreover, I would prefer to not deal with git via terminal commands but instead have VS Code do the details. I would expect the Git extension to provide all the (commonly) required functionality, not just a fraction.

[joaomoreno]

Moreover, I would prefer to not deal with git via terminal commands but instead have VS Code do the details.

So, how exactly do you run steps 10 and 11? From the command line, or from the UI?

[SetTrend]

Currently I enter the commands into the terminal (sorry for taking me so long, I'm currently busy).

It's always the same steps:

git checkout master
git merge upstream/master
git checkout myBranch
git rebase master

Then I see loads of changed files in Visual Studio Code (without having touched any file myself):

Then, wenn pressing the sync button, my history on GitHub is getting bloated with others' commits and a number of merge commits:

AFAIK, this is common procedure when committing/syncing. As I suggested, VS Code's sync button should keep the burdon off the programmer to be required to perform all the manual steps and to type all these commands manually, thereby introducing errors and faults. Not to mention the bloat in the branch's history.

I've had a number of discussions with the GitLab Runner team, the Angular team and others due to the bloated history. The reason is: the only thing people are interested in when merging a feature branch is the changes provided by the feature branch. Nothing else.

So I'd expect the sync button to (optionally) make sure that after catching up with the latest upstream master the feature branch's history to always look the same, e.g. like this:

I.e.: No repetitions, no foreign commits, no merge commits.

[joaomoreno]

AFAIK, this is common procedure when committing/syncing.

Not really. This procedure is definitely sub-optimal. You are rebasing a branch which was already pushed to a remote and pushing that up to the server again. That messy history was not created by the sync button (which will only push), but by the git rebase call you've made before that.

The golden rule is: do not rebase commits which are already on any remote. The git docs actually explain this quite well in the The Perils of Rebasing section.

Here's what I would do instead:

git checkout master
git merge upstream/master

# `myLocalBranch` was never pushed to `upstream`
# so it's fine to rebase it, those changes stay locally
git checkout myLocalBranch 
git rebase master

# `myPublishedBranch` was already pushed to `upstream`
# so rebasing it will mess up history badly
# I'll use merge instead
git checkout myPublishedBranch
git merge upstream/master

[SetTrend]

Thanks for clarifying! ❤️ 👍

I comprehend. I probably need to learn much more Git than I want to.

Actually, I tend to feel rather being a software engineer, programming things, than a VCS administrator.

Still, if the procedure you're describing is correct, then this procedure is bread-and-butter in many cases. May I suggest to add some kind of sync mechanism, incorporating and automating all this horrendous repetitive administration effort which is solely wasting valuable and creative programming time? I'd very much prefer to just hit a "send" button and continue with my work instead of getting overkilled by verifying some plain transmision.

[SetTrend]

@joaomoreno : Is the needs more info still pertinent?

[joaomoreno]

May I suggest to add some kind of sync mechanism, incorporating and automating all this horrendous repetitive administration effort which is solely wasting valuable and creative programming time?

We actually try to stay away from creating complex actions around Git operations and prefer to simply expose the Git operations themselves in the UI.

Through our extensibility story of VS Code and the Git extension, you can always contribute with an extension which implements your use case.