2

Consider the following merge:

merged code

After deleting the 'testmerge' branch, its commits remain behind.

deleted branch

Are those commits ever going to be deleted (garbage collection)? Remote prune doesn't seem to remove them...

autodidacticon
  • 1,310
  • 2
  • 14
  • 33
  • I did not get ur question, what is ur expectation? – dsharew Feb 24 '15 at 14:24
  • ehm... Your original question was: *why is this happening*? Now you're asking: *how can I do that?*. That's bad etiquette. The right thing to do, instead of editing your question and moving the goalpost, would be to accept an answer below (if one of them answered your original question to your satisfaction) and ask a *new* question. – jub0bs Feb 24 '15 at 17:18
  • You may revert the question to your edit and cease editing your comment. At that time I'll accept your answer. – autodidacticon Feb 24 '15 at 17:19
  • 1
    You can do that yourself. Click on *edited x mins ago* (located to the left of your name, above), then click on the *rollback* link corresponding to the desired edit. – jub0bs Feb 24 '15 at 17:22

2 Answers2

4

Your question most likely stems from a misunderstanding of how Git works.

In Git, branches are mere pointers to commits. Deleting a branch may render commits unreachable (in which case they would not appear on your GitHub graph), but only if the commits in question are not contained in the ancestry of any other existing reference (branch or tag). Moreover, garbage collection / pruning of commit objects only applies if those objects are unreachable.

In this case, based on your screenshots, the repo looks as follows (before the deletion of testmerge):

-- A ----------- E [development]
    \           /
     B -- C -- D [testmerge]

Note that commits B, C, and D, in particular, are reachable from testmerge; in other words, they're contained in the ancestry of the tip of branch testmerge (commit D). However, they're also ancestors of the tip of branch development (commit E). Because those three commits are reachable from development, deleting testmerge will not make them "go away":

-- A ----------- E [development]
    \           /
     B -- C -- D

And because those commits are still reachable (from development), running Git's garbage-collection mechanism will not affect them.

jub0bs
  • 60,866
  • 25
  • 183
  • 186
  • 1
    Good answer. I would add a small excurse on what a merge commit is in git; speaks multiple parents, which makes the commits in question still reachable. – Sascha Wolf Feb 24 '15 at 14:59
  • 1
    @Zeeker Thanks. I don't know; the OP seems to know what a merge is. I'll wait until s/he sees this answer and I'll expand it if needed. – jub0bs Feb 24 '15 at 15:14
2

Those commits will never be removed, so long as the development branch is live (or merged into another live branch, or included as part of the history of a tag).

The reason is git commits are actually objects, each object having references to the current state of the repository, the author and committer information, the commit message, and of course, the parent commit or commits (in the case of merge commits)

As the HEAD commit on your development branch has a reference to the former HEAD commit of the testmerge branch, the branch is "kept alive".

A reference on Git Objects that you may find useful: http://git-scm.com/book/en/v2/Git-Internals-Git-Objects

You may also be interested in various questions around pruning history: How do I remove the old history from a git repository?

Also if this is undesirable, consider rebasing and squashing your branch to a single commit before doing a fast forward merge in the future.

Community
  • 1
  • 1
Charlie
  • 7,181
  • 1
  • 35
  • 49