Timeline for Is the git "Golden Rule of Rebasing" so essential?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 13, 2017 at 9:04 | comment | added | Joel | Actually, rebase is like saying: "let's rewrite all my work from scratch (from latest master), deleting all my previous work.". If you're ok to do that, you're ok to rebase. | |
| Jul 13, 2017 at 8:57 | comment | added | Joel | PS: thanks for the Changeset evolution link, that's interesting | |
| Jul 13, 2017 at 8:52 | comment | added | Joel | ... , and if some people wants to bring modification to that PR then I consider they should tell me first, and it's a matter a communication. (2/2) | |
| Jul 13, 2017 at 8:52 | comment | added | Joel | I agree with this "git philosophy" and I also think philosophies can sometimes be hacked :). More seriously, as I stated in the comments, that's now 3 years ago, I was in the particular case of having gerrit as a code-review tool which acted as a de-facto backup tool, preventing such potential dramatic loss. Now I still think rebase is OK when you're sure to "control" a branch. Even in an opensource project, if I'm developing a feature and open a pull request, I "own" that PR, I consider I have the right to rebase its branch, it's up to me not to fuck up my own work during rebasing... (1/2) | |
| Jul 12, 2017 at 4:13 | history | answered | Kevin | CC BY-SA 3.0 |