From: "Angelo Borsotti" <angelo.borsotti@xxxxxxxxx>
Sent: Wednesday, October 03, 2012 12:52 PM
Hi
You still didn't tell us where the problem was.
I've split up the explanation of your problem you have seen, to see if I
can understand where the 'missing' aspect is within the extended
dicussions.
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.
What isn't clear is how the master branch is created and maintained at
this point.
Does the script create it afresh each time, so that it is also,
implicitly, an --orphan branch?
I ended up with a branch "master" and a branch "new-branch", both
pointing to the same commit. The new branch _is_ created.
In such a case (a new master being created every time the script runs),
then you can suffer the situation you describe where you have a common
sentinel commit being used for both branches, even though you thought
they were orphaned from each other. - a very special case.
However one has to ask how the rest of the script would work in such
situations with such a truncated master branch.
If the master branch has a true history, then you would get different
commits being created on the two branches because the parents would be
different.
Or finally, you have a truly special test (initialisation) case when you
are starting master (which will later grow) and comparing it to the very
first test case of the --orphan branch and in that special case you
could get a common commit. But that is a one off special case, and would
not recur in practice.
Can you say more about the script?
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