5

Newbie open-source contributor here.

I forked the TortoiseGit repository on GitLab, then cloned it on my computer, edited one file, and committed to branch master.

A few days have passed and I want to update my local working copy with the latest changes from upstream, before pushing to my remote fork and opening a merge request (and of course doing more development/testing etc).

I added a remote called upstream to my repo and now I'm not sure what would be the recommended action:

  1. git pull from upstream/master to my checked-out branch master
  2. git pull --rebase //
  3. git fetch followed by git rebase.

These are the approaches I found during my research. Unfortunately I could not find a comprehensive review of each, nor a recommendation as to which one is typical practice when working in projects from GitHub, GitLab or even those like the Linux kernel.

I tried methods 1 and 3. Method 1 (pull) generates a merge commit (--ff-only is not possible) and my history is, in a way, polluted. It also creates conflicts. Method 3 (rebase) does neither, but I'm not sure how rebase behaves after commits are pushed to remote and so I'm afraid it might cause problems going forward.

So there's my question.
Thank you.

Marc.2377
  • 7,807
  • 7
  • 51
  • 95
  • Possible duplicate of [How do I update a GitHub forked repository?](https://stackoverflow.com/questions/7244321/how-do-i-update-a-github-forked-repository) – alfunx Apr 04 '19 at 05:11

2 Answers2

3

TortoiseGit team member here.

I added a remote called upstream to my repo and now I'm not sure what would be the recommended action:
1. git pull from upstream/master to my checked-out branch master
2. git pull --rebase //
3. git fetch followed by git rebase.

Different team uses different workflow.
See Pro Git (v2) - 5.1 Distributed Git - Distributed Workflows

In TortoiseGit team, we prefer keep the history simple, and contributor usually has the responsibility for resolving the conflicts while rebasing.

So, most of the time, we use "git fetch followed by git rebase", especially when contributing. Then, as you said, creating pull/merge request (by using git push), or updating the pull/merge request (by using git push with force) on GitHub/GitLab.

See How Can I Contribute? and HowToContribute.txt for other detail information.

Yue Lin Ho
  • 2,945
  • 26
  • 36
  • Hi, thanks for weighing in. Since you offer a little more practical advice, allow me to as for clarification also in a more practical manner. If you can have a look at my fork (https://gitlab.com/ranolfi/tortoisegit/commits/master), I made 3 commits from 2019-03-16 and when I went with strategy #1 (`pull`) a merge commit was generated (on 2019-04-03). If I open a GitLab merge request for these 3 commits from March, and they get accepted, can I stick to this strategy going forward? I dislike merge commits in my repo, but it's my personal repo and the merge commits should not end up in (...) – Marc.2377 Apr 13 '19 at 02:25
  • _(cont)_ the main (upstream) repository, right? The way I understand your answer, it is a matter of chosing between having merge commits in your repo _vs_ having to force push every time you rebase (unless, _perhaps_, if my merge request is approved in the meantime). Do you still advise fetch and rebase? – Marc.2377 Apr 13 '19 at 02:28
  • 1
    Answer your question here: https://gitlab.com/ranolfi/tortoisegit/issues/1#note_161164061 – Yue Lin Ho Apr 16 '19 at 06:57
1

I forked the TortoiseGit repository on GitLab, then cloned it on my computer, edited one file, and committed to branch master A few days have passed and I want to update my local working copy with the latest changes from upstream

If by upstream you're referring to the main repo, you can

  1. git fetch origin
  2. git rebase origin/master

assuming origin points to the main repo

Rebasing replays the commits of your current branch (your local master branch) on top of the branch you're rebasing origin/master in this case, which is a reference to the current master branch of origin.

For example:

master branch before your commit:

  • c
  • b
  • a

master branch after your commit:

  • xxx <- your commit
  • c
  • b
  • a

After a few days, TortoiseGit git commits to origin/master which now looks like this.

  • 3
  • 2
  • 1
  • c
  • b
  • a

You sync the changes by fetching and rebasing on top of origin/master. Your local master branch will now look like this:

  • xxx <- your commit
  • 3
  • 2
  • 1
  • c
  • b
  • a

I added a remote called upstream to my repo and now I'm not sure what would be the recommended action

then you can simply git push upstream master to update your fork.

Noel
  • 370
  • 3
  • 9
  • rebase sounds to me kinda dangerous, rebase seems to work bad when files are renamed, moved, split, etc. Rebase might be efficient, maybe I try it. Rebase more efficient then merge ?! But maybe merge is safer... keep master branch a copy of the original and maybe work on branches and then merge was my initial idea for git... I see another little problem with this rebasing, what if the commit was already pushed to repository... hmmm ? At least with working on seperate branch maybe less of an issue ?! Seems easier to just keep main master a copy and keep it intact. Perhaps rebasing from branch. – oOo Dec 01 '20 at 17:27
  • There are trade-offs to both. Merge: Pros: - Conflict resolution in 1 commit. - Cons: - Messy history - Easy for bad code to hide itself - Impossible to edit a commit before merge point Rebase: - Pros: - Clean history - You can always re-organize your PR history if you want - You can edit/remove any commit - Cons: - Sometimes you'll encounter conflicts that may affect multiple commits in which you need to be extra careful in resolving them. Messing up conflict resolution messes up your history, but can be undone with `git reflog`. Cherry-picking helps too. – Noel Dec 03 '20 at 10:24