4 ms·
This is how I used to do it, but now I've come around to using --no-ff. The reason for this is that it allows easy visualization of the actual branch developme
by dasil003 11y ago
This is how I used to do it, but now I've come around to using --no-ff. The reason for this is that it allows easy visualization of the actual branch development without scrutinizing commit metadata. And it does so without any loss of linearity, because the second parent commit is already an ancestor of the first parent, therefore you have the property that the merge commit never has any conflict resolution in it, and you lose no git-bisect fidelity. The more I thought about it the more I found this to be win-win and changed my teams workflow a couple years ago.
- kazinator 11y agoSince I don't use "git merge", I have no use for --no-ff. (See "rebase or die" quip in parent.) git rebase does take --no-ff, but it is silly (except in some special cases, when rewriting strictly local history). (I can't think of what those special cases are). If you do a fetch and have diverged from upstream changes, "git rebase --no-ff" will rewrite those upstream changes, rather than fast-forward over them, which you almost certainly don't want.
- dasil003 11y agoYou're not engaging with my actual point. Post-hoc delineation of topic branches without the effective loss of linearity is superior. Prove me wrong.