3 ms·
Not all history is sacrosanct. REMOTE history is absolutely sacrosanct (A remote being any repository that someone is going to pull from), but you can do whate
by knowtheory 16y ago
Not all history is sacrosanct.
REMOTE history is absolutely sacrosanct (A remote being any repository that someone is going to pull from), but you can do whatever you like with your local repository, so long as you only push from it.
- acqq 16y agoOK, but I believe remote repo is there only to be pushed to, so then is there any example of benefit of pull without --rebase if the pull is anyway only done locally? http://progit.org/book/ch3-6.html http://progit.org/book/ch3-6.html Says " If you rebase commits that have already been pushed publicly, and people may have based work on those commits, then you may be in for some frustrating trouble." but not how that can happen at all, provided you always "pull --rebase" and then "push", and if that can happen at all, then what to do.
- kemiller 16y agoSacrosanct? No. But still useful. With a real merge, you get a special commit that summarizes what had to be done to complete the merge. That can come in handy, especially with the sort of bugs that creep in during merges. Rebase will actually change your original commit, which obscures the original intent of the commit and hides the merge. In those cases I'd rather have a slightly messier history but more information about what really happened.