4 ms·

I think this is a great tool. I don't understand what other commenters are complaining about rebase and rewriting history, because this article is not about th

I think this is a great tool. I don't understand what other commenters are complaining about rebase and rewriting history, because this article is not about that, it's about not having to fix conflicts multiple times. This can be handy in a variety of situations. You might not need it, but every person/team has it's own way of working with Git. Rerere is just another tool that might help you in your workflow. And to the people who are claiming that rebasing is hard, dangerous or a clean history is not necessary: Once you get it's not hard or dangerous, and a clean history really IS useful. Why are we using Git again? - Being able to work together on a codebase (the history shows the changes) - Code reviews for new features (the history of the pull request shows the changes the feature introduces) - Being able to roll back to a previous state in case there is something wrong with the latest version (the history can help you decide where to roll back to) And a lot of more reasons we use Git that have to do with the history. It is true it takes a little bit more effort to have a clean history, but in big teams/projects it's really worth it.

thewarrior 12y ago
I agree with you for the most part but most of you would be better off if you keep this in mind : Don't rebase commits you have already pushed.
- sytse 12y ago
  Exactly, if you have pushed it other developers might have referenced, merged or cherry-picked your code. Even if you marked it as a work in progress. And to roll back to a previous state it is not needed to rebase and/or have a linear history. Also see my article about this https://about.gitlab.com/2014/09/29/gitlab-flow/ https://about.gitlab.com/2014/09/29/gitlab-flow/
- gitaarik 12y ago
  A good usecase for pushing rebased work is at the end of a feature branch. For example, you've been working on a feature branch with a team for a time and now the feature is done and the branch can be merged back into master. However, the history of the feature branch might have been polluted with merge commits. To prevent merging these merge commits back into master, you can rebase the total feature branch on to master. It should be clear to the team that at this point, nobody is to work on that branch anymore and go back to master, or create a new branch (from master).
  - sytse 12y ago
    GitLab CEO here. I personally don't like this workflow since you lose the history of what you did tested and it someone cherry-pick/referenced or merged code it will give problems. But some organizations prefer this workflow and if everyone is aware that they should not reference code it feature branches it can work. The linear history is certainly nice. The rebase just before merge is a bit of work. In GitLab Enterprise Edition there is an option to do this automatically when pressing the merge button.
- marrs 12y ago
  Git won't let you push a modified history without a force anyway, and you can set up the remote to refuse these pushes if you want.

thewarrior 12y ago

I agree with you for the most part but most of you would be better off if you keep this in mind : Don't rebase commits you have already pushed.

sytse 12y ago
Exactly, if you have pushed it other developers might have referenced, merged or cherry-picked your code. Even if you marked it as a work in progress. And to roll back to a previous state it is not needed to rebase and/or have a linear history. Also see my article about this https://about.gitlab.com/2014/09/29/gitlab-flow/ https://about.gitlab.com/2014/09/29/gitlab-flow/
gitaarik 12y ago
A good usecase for pushing rebased work is at the end of a feature branch. For example, you've been working on a feature branch with a team for a time and now the feature is done and the branch can be merged back into master. However, the history of the feature branch might have been polluted with merge commits. To prevent merging these merge commits back into master, you can rebase the total feature branch on to master. It should be clear to the team that at this point, nobody is to work on that branch anymore and go back to master, or create a new branch (from master).
- sytse 12y ago
  GitLab CEO here. I personally don't like this workflow since you lose the history of what you did tested and it someone cherry-pick/referenced or merged code it will give problems. But some organizations prefer this workflow and if everyone is aware that they should not reference code it feature branches it can work. The linear history is certainly nice. The rebase just before merge is a bit of work. In GitLab Enterprise Edition there is an option to do this automatically when pressing the merge button.
marrs 12y ago
Git won't let you push a modified history without a force anyway, and you can set up the remote to refuse these pushes if you want.