0

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?

Stefan Monov
  • 11,332
  • 10
  • 63
  • 120
  • Your description of why you don't like fast-forward is based on an incorrect understanding of what fast-forward merges do. In the scenario you outline, git will refuse to perform a fast-forward at all. Fast-forwards *never* re-order commits. – Mark Adelsberger Aug 25 '17 at 15:34
  • As @MarkAdelsberger said, `git merge` *doesn't* interleave commits. What does is `git log`, if you run it without appropriate arguments. The history is all there intact, but `git log` *by default* shows it in time order, rather than graph order, so if Bob committed at 1 and 3 PM while Carol committed at 2 and 4 PM, `git log` will linearize it that way ... unless you tell it: no, show them to me in a non-interleaved order. Graphical viewers like `gitk` can be helpful here as well. – torek Aug 25 '17 at 16:49
  • @torek: Thanks, good to know! – Stefan Monov Aug 25 '17 at 17:12

0 Answers0