1

This is my situation:

After having cloned a repository, I updated my remote's master branch and created a few branches from it:

branching scheme

Now, syncing my branches with the upstream master branch seems to become a mess (see discussion hyperlinked above):

When I merge the upstream's master to my master and then rebase my branches, all the upstream history that accumulated between my original cloning operation and today seems to add to my history.

How can I solve this?

All files/changes I want to appear in my merge/pull request is only the changes I made - nothing else.

AxD
  • 2,714
  • 3
  • 31
  • 53
  • Your branch seems to be called "Windows-Admini-Privileges-HowTo" - notice the typo Admini instead of Admin. Your pull request currently sources from the branch without the typo. – Andreas Jan 06 '19 at 16:55
  • Actually, the branch was `Docs-Windows-Admin-Privileges-HowTo`. I already deleted it as suggested in the MR's discussion. – AxD Jan 06 '19 at 23:28

1 Answers1

2

The normal way to update your merge request is to:

  • fetch from upstream ("upstream" being the remote referencing the original repo, the one you forked)
  • rebasing (not merging) your local branches on top of upstream/master

If for some reason that does not work (because it includes too many commits)

  • rename your current branch to "old_my_branch"
  • recreate your branch on top of upstream/master
  • cherry-pick your old branch commit to your new local branch
  • force-push that new local branch to your existing remote branch: the associated merge request will update itself.
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Currently, when I `git checkout master` I receive a message telling me that ``` PS C:\Users\*\go\src\gitlab.com\gitlab-org\gitlab-runner> git checkout master Already on 'master' Your branch is ahead of 'origin/master' by 28 commits. (use "git push" to publish your local commits) ``` So, you're suggesting me to: ``` git fetch upstream git checkout master git rebase upstream/master git checkout Docs-Windows-Admin-Privileges-HowTo git rebase master git push ``` – AxD Jan 06 '19 at 23:33
  • git rebase upstream/master: replay your branch commits on top of the (up-to-date) master from upstream. – VonC Jan 07 '19 at 00:49
  • @AxD Your local master should not be ahead of the upstream/master. It should always be exactly the same as upstream/master. You must not merge into your local master unless you plan to push it to upstream. Your local master and upstream/master should remain in sync. Maybe you can rebase your feature branch on upstream/master instead of your local master and then push it. You can create a "restorepoint" branch from your feature branch so that you may reset to it in case something goes wrong. – Andreas Jan 07 '19 at 10:56
  • @Andreas Considering a merge request is always (or should always be) done from a dedicated branch, I would argue the state of the local master branch does not matter much. – VonC Jan 07 '19 at 11:30
  • Er ... I'm lost. What would be the slickest way to get things done without being required to rebuild my whole repository? Is it necessary to restore my master to match default upstream? How would I do that? – AxD Jan 07 '19 at 15:10
  • @AxD no, no need to worry about master: you are working in branches anyway (meaning you are not working or committing on your local master branch). As I describe in the answer: fetch from the original repo, rebase your merge request branch on top of the upstream/master branch, and force push. Done. – VonC Jan 07 '19 at 15:14