Orphan commits are created when there is no tag or branch that contains them in its graph of parent commits. For example, if you make a branch foo
, add commits a
and b
, then delete the branch (i.e. remove the reference foo
from commit b
), then both a
and b
will not be reachable unless you saved their hashes.
x-x-x-x <- master
\
a-b <- foo (reference then deleted or reset to somewhere on master)
Basic Git behavior on orphaned commits is to eventually garbage collect and delete them (I have heard the default is at least 30 days).
Will Git ever move orphan commits from one repo to another using the git clone
, git fetch
, or git push
commands?
Or does Git effectively ignore these commits for any operation that does not directly call out an orphan's hash (such as checkout
or cherry-pick
)?
During normal Git workflow, those commits are ignored. This includes git clone
, git push
, and git fetch
. But depending on the Git repo hosting server, you might be able to pull them back in your repo, if that is needed.
That is what I described in "Does github remember commit IDs?": through the GitHub Event API, you can get back the SHA1 of a (for instance) deleted branch, and restore it that way in your own repo.
That compensates for the fact a git reflog
is generally not accessible/public on the remote side.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With