Hi >>> You still didn't tell us where the problem was. I thought I did, but here it is: I have private and a public repositories. In the private ones the developers keep both the sources and the binaries. In the public ones they keep only the sources. They do not want the binaries there because binaries are very large and requite much time to be pushed. Besides that, they are not even needed because they must be rebuilt anyway. To push the sources only they keep in the private repositories an orphan branch in which commits are done taking the relevant commits in the (say) master branch and removing the binaries from the index. Pushing directly the master branch would push also the binaries even if they were removed from its index (the history gets pushed): thence the need for an orphan branch. Scripts have been provided to do this easily and safely. Now, it could happen that a developer does not have (yet) binaries, but want to push all the same. The script has to take care for this special case, in which no binaries are removed, but a commit on the orphan branch is done all the same. And here is the problem since git commit does not produce a brand new, different & unique commit all the times, making then the orphan branch point to the master one, i.e. becoming a non-orphan one. > I ended up with a branch "master" and a branch "new-branch", both > pointing to the same commit. The new branch _is_ created. > Exactly, it is created, but it is not an orphan ... or more precisely, it is sometimes, depending on how fast you are to enter the second commit command. This time-dependent behaviour is what I am talking about. -Angelo -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html