0

I've been working on a project for some time using a git local repository for version control.

I have two branches in the repository: master and "other" (not its real name).

When I run git branch I get this list:

  other
* master

Looking at my repository graph with gitg (a Gnome GUI for git), selecting "all branches" from the branches drop-down list, I get this graph:

enter image description here

I see the two branches, but there are also two commits, tagged "v1.2y" and "v1.2s", that stick out of the master branch and don't seem to merge back into it. They seem to be hanging there like non-merged-back branches, but they are not actual branches. At least neither git nor gitg list them as being branches.

Can someone explain to me the reason they stick out of the master branch if they are not branches themselves?

Please don't just simply tell me what to do to make it normal but, most importantly, the reason why this happened to begin with.

EDIT: I have never made a rebase or force push.

Tulains Córdova
  • 2,559
  • 2
  • 20
  • 33

1 Answers1

3

First of all, you can read about the difference between tags and branches here: How is a tag different from a branch? Which should I use, here?

Suppose you do the following:

git checkout master                      //go to branch master, say at commit x
git checkout -b newbranch                //create a new branch called newbranch that also points to x
git commit -a -m some_branch_commit_1    //add a commit to newbranch
git tag tagged_my_commit                 //tag your commit
git checkout master                      //go back to master
git commit -a -m "Something"             //add a commit, say y to master 
git checkout newbranch                   //go back to newbranch
git rebase master                        //create a copy of the commits on newbranch so that they now split of from y instead of x

In this case, a new copy of commit some_branch_commit_1 will be created. However, the old one still exists (it was tagged tagged_my_commit) so it will never disappear. Basically, you now have two copies of the same commit, one of them is not on a branch with a particular name.

Suppose however you didn't tag that commit, then in principle it could be removed by git. However, deleting such commits (garbage collection) only happens from time to time. This can explain why commits that shouldn't keep on existing still are in your repostiroy. If you want to read more, see https://git-scm.com/docs/git-gc

As noted in the comments, this does not only happen with rebases. Any form of rewriting (e.g., amending commits, changing the pointer of a branch, ...) can lead you to this situation.

EDIT as requested: another example

git checkout master                  //go to master, say at commit x
git commit -a -m "I did something"   //create a commit, say y1
git tag tagit                        //tag your commit

your history now looks like this

y1  = master  =  tagit
|
x

Now do the following //edit some file
git commit -a -m "I did something (more)" --amend //change commit y1 such that it now also takes changes to the other file into account, say this is y2

In that case your history looks like this

y1=tagit  y2=master
|         /
|        /
|       /
|      /
|     /
|    /
|   /
|  /
x

which seems to be like in your situation

Community
  • 1
  • 1
BartBog
  • 1,889
  • 14
  • 28
  • I have never made a rebase. In fact I don't know how that works. I don't think I made a rebase by accident. Would you please explain the situation without using rebase as an example? Also it would be more helpfull if you put comments beside each command instead of a separate paragraph since I don't seem to be able to follow. – Tulains Córdova Nov 18 '15 at 14:28
  • I know the difference between a tag and a branch. In my question I state that those weird commits stick out of the main branch without being branches. – Tulains Córdova Nov 18 '15 at 14:46
  • That comment about tags and branches was simply because tags, as well as branches can "keep commits alive". In your question, you seemed to be wondering why certain commits stayed alive even though they are no branches – BartBog Nov 18 '15 at 14:55
  • Thanks for improving the answer. Does amending create another commit? I thought it just re-wrote the existing one (y1). If it does create another commit (y2) like the drawing implies, are changes in y2 part of the master branch? Also, is y1 not part of the master branch anymore? or are both part of the master branch despite looking like a fork? – Tulains Córdova Nov 18 '15 at 14:58
  • The SHA of a commit is based on its contents. So if you change the contents of a commit, you also change its "unique name". As can be seen in my drawing. y1 is no longer part of the master branch. The master branch is ```x - y2``` y1 is now a "loose commit" – BartBog Nov 18 '15 at 15:02
  • Ok now I know what happened, I tagged a commit and later in time I amended it. The tag keeps it "alive". What would happen if now I deleted the tag from y1 (or tag v.1.2y in my question) ? Would the phantom commit disappear from the graph? – Tulains Córdova Nov 18 '15 at 15:07
  • It might disappear, but not immediately. It disappears when git performs garbage collection – BartBog Nov 18 '15 at 15:09