git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: erratic behavior commit --allow-empty

From
Philip Oakley <philipoakley@iee.org>
Date
Oct 3, 2012, 22:32 UTC
Message-ID
<A75F75C4DE3C47C7AF43D39355C873F7@PhilipOakley>
In-Reply-To
<CAB9Jk9BTCaV7RDx6_K+MKOeJTdOQPOwvnGM0UNxg9S8KMo4D4Q@mail.gmail.com>
From: "Angelo Borsotti" <angelo.borsotti@gmail.com>
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:
Show 6 quoted lines
> 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?
Show 7 quoted lines
> 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
> --
Previous: Matthieu MoyNext: Angelo Borsotti
Message 21 of 53 in “erratic behavior commit --allow-empty”
  1. Angelo BorsottiOct 2, 2012
  2. Johannes SixtOct 2, 2012
  3. Angelo BorsottiOct 2, 2012
  4. Junio C HamanoOct 2, 2012
  5. Angelo BorsottiOct 2, 2012
  6. Junio C HamanoOct 2, 2012
  7. Angelo BorsottiOct 2, 2012
  8. PJ WeisbergOct 3, 2012
  9. Johannes SixtOct 3, 2012
  10. Angelo BorsottiOct 3, 2012
  11. Johannes SixtOct 3, 2012
  12. Philip OakleyOct 3, 2012
  13. Angelo BorsottiOct 3, 2012
  14. Matthieu MoyOct 3, 2012
  15. Angelo BorsottiOct 3, 2012
  16. Matthieu MoyOct 3, 2012
  17. Angelo BorsottiOct 3, 2012
  18. Matthieu MoyOct 3, 2012
  19. Angelo BorsottiOct 3, 2012
  20. Matthieu MoyOct 3, 2012
  21. Philip OakleyOct 3, 2012
  22. Angelo BorsottiOct 4, 2012
  23. Phil HordOct 4, 2012
  24. Angelo BorsottiOct 4, 2012
  25. Philip OakleyOct 4, 2012
  26. Angelo BorsottiOct 4, 2012
  27. Philip OakleyOct 4, 2012
  28. Angelo BorsottiOct 4, 2012
  29. Tomas CarneckyOct 3, 2012
  30. Angelo BorsottiOct 3, 2012
  31. Andreas SchwabOct 3, 2012
  32. Angelo BorsottiOct 3, 2012
  33. Andreas SchwabOct 3, 2012
  34. Angelo BorsottiOct 3, 2012
  35. Andreas SchwabOct 3, 2012
  36. Angelo BorsottiOct 3, 2012
  37. Andreas SchwabOct 3, 2012
  38. Angelo BorsottiOct 3, 2012
  39. Andreas SchwabOct 3, 2012
  40. Phil HordOct 3, 2012
  41. Angelo BorsottiOct 3, 2012
  42. PJ WeisbergOct 3, 2012
  43. Angelo BorsottiOct 3, 2012
  44. Andreas SchwabOct 3, 2012
  45. PJ WeisbergOct 3, 2012
  46. Lars NoschinskiOct 5, 2012
  47. Jan EngelhardtJan 12, 2013
  48. Joachim SchmitzJan 16, 2013
  49. Johannes SixtOct 3, 2012
  50. Angelo BorsottiOct 3, 2012
  51. Junio C HamanoOct 3, 2012
  52. Angelo BorsottiOct 3, 2012
  53. Phil HordOct 3, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.