5 ms·

Or rebase onto the head of Master instead?

by joelthelion 7y ago

jayd16 7y ago
The whole article is about the problems with that and the pain of working around it.
- bsaul 7y ago
  Actually that's something i don't get (but i'm not a git pro by any means). The article doesn't seem be about the pain to rebase, but rather the pain of regular merging polluting the history. Regularely rebasing the branch on master doesn't pollute anything, keep the branch in sync with master, and makes for a happy final commit.
  - jayd16 7y ago
    When you rebase a lot you might have to do the same merge operation multiple times, unless you change the settings like is shown in the article. The trick here saves the merge resolution locally so you can automatically merge again if you have to. I don't think this gets pushed so anyone else (or you but in a different repo) on that branch would also need to repeat the merge operation though. If you save the merge commit, the merge itself is in the history so there's nothing to repeat.
  - dahart 7y ago
    This is a good point. The author wanted to talk about rerere, and control merges are a great motivator for that. If he rebased the branch, then he wouldn’t be able to write about git rerere. :) That said, rebasing a branch several times before merging back to master is something you can easily do if you’re the only person in the branch. When there are multiple people pushing to the branch, and when the branch changes are large, rebasing becomes impractical and even dangerous. You don’t want to rebase a branch while others are working in it, because it would require a force push. I’d say rebase the branch when you can, which is usually if it’s a private branch and you’re the only person who made changes. Merge into the branch as you go if the branch is large and has multiple people. Commit the merges if you want people in the branch to do integration testing along the way. Use control merges and don’t commit them if you want to keep the branch stable and buffer the people in the branch from changes in master.

Or rebase onto the head of Master instead?

jayd16 7y ago

The whole article is about the problems with that and the pain of working around it.

bsaul 7y ago
Actually that's something i don't get (but i'm not a git pro by any means). The article doesn't seem be about the pain to rebase, but rather the pain of regular merging polluting the history. Regularely rebasing the branch on master doesn't pollute anything, keep the branch in sync with master, and makes for a happy final commit.
- jayd16 7y ago
  When you rebase a lot you might have to do the same merge operation multiple times, unless you change the settings like is shown in the article. The trick here saves the merge resolution locally so you can automatically merge again if you have to. I don't think this gets pushed so anyone else (or you but in a different repo) on that branch would also need to repeat the merge operation though. If you save the merge commit, the merge itself is in the history so there's nothing to repeat.
- dahart 7y ago
  This is a good point. The author wanted to talk about rerere, and control merges are a great motivator for that. If he rebased the branch, then he wouldn’t be able to write about git rerere. :) That said, rebasing a branch several times before merging back to master is something you can easily do if you’re the only person in the branch. When there are multiple people pushing to the branch, and when the branch changes are large, rebasing becomes impractical and even dangerous. You don’t want to rebase a branch while others are working in it, because it would require a force push. I’d say rebase the branch when you can, which is usually if it’s a private branch and you’re the only person who made changes. Merge into the branch as you go if the branch is large and has multiple people. Commit the merges if you want people in the branch to do integration testing along the way. Use control merges and don’t commit them if you want to keep the branch stable and buffer the people in the branch from changes in master.