1

Why after merging explicitly with the --no-ff flag some feature branch onto a clean master (no new commits since branching), I can see the full commit history of the feature branch when checking out master?

The situation could be represented with this ASCII graph:

A-----------E -> master # E is a merge commit
 \         /
  B---C---D -> feature

If something happens in master and I want to revert it to commit A, a previous stable point in history, I have to somewhat filter commits B, C and D because a simple git log --oneline shows them (maybe with --not feature argument?). In a certain sense it's logical because these commits are reachable from the tip of master.

My use case is a pristine master with temporary feature branches as needed, pretty common I guess. How projects usually deal with this continuous integration scenario?

1 Answers1

0

Reading between the lines, maybe what you want to use is git merge --squash.

See the accepted answer here for more: How to use git merge --squash?

Apologies if this doesn't answer the explicit question. I hope it answers an implicit one.

Community
  • 1
  • 1
Chris Lear
  • 6,592
  • 1
  • 18
  • 26
  • Meanwhile I've found `git revert [-m parent-number]`. Some people say that rewriting history is not a good idea, others think different http://jamescooke.info/git-to-squash-or-not-to-squash.html –  Oct 08 '15 at 10:03
  • I don't use `git --squash` myself, and I don't use `rebase` either. But they're worth knowing about. There isn't just one answer with git. – Chris Lear Oct 08 '15 at 10:06
  • Maybe is just a matter of conveniently formatting `git log` output. `--first-parent` could do the trick... Anyway I'd like to read another opinions :) –  Oct 08 '15 at 10:16