0

I prefer to merge my feature branches with --squash as it lets me track when features were added, and it is usually complete features that I need to bisect on. I find that this gives a very nice representation of the state of the stable branch over time.

However, when using --squash branches merged appear under --no-merged instead of under --merged. This makes it sometimes difficult to keep track of the state of each branch (i.e. when it is finished). I do not want to delete the 'finished' branches as it has happened that I have had to check them out to bisect further and also other reasons (sometimes a problem requires multiple paths of attack until it is solved, and I have found it valuable to have that documented).

It there any way to either:

  • Have --merged and --no-merged recognise that squashed branches have in fact been merged.

or

  • Archive merged (squashed) branches in the sense that they will not appear in either listing, but are still available if I need them.

I actually do prefer the second solution if possible. There are quite a few non-current branches accumulating and hiding them will make it easier to search the list for the current branch that I am looking for.

dotancohen
  • 30,064
  • 36
  • 138
  • 197

2 Answers2

1

Branches are merged, if—and only if—another branch has them as a direct or indirect parent (i.e. when following the parents of the commits, you will at some time reach that branch). There are no exceptions from this.

When you squash changes, you are creating a new commit object that contains all the changes from that one branch at once. So you have a “new branch” for that one commit, and the old branch stays around to keep the original commits available. Now when you merge, you merge that one commit, so only that one’s branch gets merged.

So no, when you squash the changes, the original branch that still contains the individual commits won’t be recognized as merged, simply because it isn’t merged. There is also no way to change this behavior, or to “archive” a branch. The only thing you could do is to create a tag for the branch instead, as a marker, so you can then delete the branch itself.

However, the proper way is to just merge the full branch. Especially if you are saying that you want the original branch “still available if [you] need them”. If you want that, then you should just keep the original branch inside the history, so it’s a real part of the history.

If you worry about the readability of the history, you should consider making non-fast-forward merges all the time, so the branches you merge in always appear separately on the side.

poke
  • 369,085
  • 72
  • 557
  • 602
0

You could just merge normally (without squashing) and use the --first-parent option to your git commands. For example

git log --first-parent

to "simplify" history. This will simplify the feature branch to a merge commit entry only and you will not see the commits on the merged branch.

slobobaby
  • 696
  • 7
  • 10