4 ms·
No rebase please. Let's keep the history accurate.
by Randgalt 13y ago
No rebase please. Let's keep the history accurate.
- mpyne 13y agoThat's just it. It does keep the history accurate, if you're literally just trying to grab updates from upstream. Unless you're actually working on, or merging, a separate branch then normally rebase is what you want.
- DoubleCluster 13y agoIt does NOT keep history accurate. You have absolutely no guarantee that all rebased commits work as intended or can even be built. The only thing that can be rebased safely is a single commit, for the rest you should learn to live with a messy history. It doesn't really matter anyway as long as you have procedures to prevent criss-cross merges.
- Zombieball 13y agoRun unit tests after rebasing & before pushing?
- mpyne 13y agoIf you require that each individual commit meets semantic criteria then you can still require that to occur during a git rebase by rewriting the commit. Which you should probably be doing anyways, if you're pulling breaking changes from upstream.
- ibrahima 13y agoExactly. It makes sense to rebase for a single commit or two when you're syncing with a remote frequently, but in any other case merge is much more sane.
- __david__ 13y agoHaving "git log -p" be readable is infinitely more important than so called "accurate" history.