I wanted to decide whether to use the --no-ff option (when merging).
I read this article: Understanding the Git Workflow. Quote from there:
Unfortunately, your feature branch contained checkpoint commits, frequent commits that back up your work but captures the code in an unstable state. Now these commits are indistinguishable from Master’s stable commits. You could easily roll back into a disaster.
But in fact, that possibility doesn't worry me. So it's not a reason to use --no-ff for me. Nor, for me, is it a reason to "before merging, clean up my branch with tools like reset, rebase, squash merges, and commit amending.", like the author suggests.
I want to use --no-ff for another reason though: it lets me easily which commit is about which feature. IOW, it lets me keep each feature tucked separately, so I can browse it separately. Basically the same reason for which I use a hierarchical filesystem with folders, subfolders and files.
Also another reason: I don't like how plain git merge creates a nonsensical interleaved history. Example (within a single day):
Commits in branch master:
- mFoo, committed at 1pm
- mBar, committed at 3pm
Commits in branch feature:
- fFoo, committed at 2pm
- fBar, committed at 4pm
A plain git merge would create this history:
mFoo, fFoo, mBar, fBar
So now if I go back to mBar, I'll get part of feature's changes as well,
which makes no sense - they may not even be compatible with mBar.
It seems that these preferences of mine doesn't conflict conceptually with git blame and git bisect's proper functioning, but for some reason apparently I cannot have both.
Can you tell me what that reason is, and whether there's a workaround?