On Mon, 30 Mar 2015 09:54:05 -0700 (PDT) Frank Gutierrez <[email protected]> wrote:
> *UPDATE* > > *refs/heads files do _not_ point to objects* > > path: objects/78/803b535 > path: objects/4c/c30382a > path: objects/b9/9cd833e > path: objects/4a/a4629d6 > path: objects/58/8734ab5 > path: objects/57/7ffcd9c > ... > ... > > > I checked the paths and they are not in the objects subdirectory The objects need not necessarily be files under the objects/ directory: for efficient storage, Git only allows a moderate number of objects be stored this way; most objects get compressed into the so-called "pack files". The objects stored "as is" are called "loose". So your branches need not necessarily point to loose objects, and they might legitimately point to objects stored in one of the pack files. To verify the repository's integrity, you might want to run the git fsck command on it. > I'm thinking a rebase might be the culprit > > But how to fix??? While I think this your problem is a non-issue (as explained above), if you're afraid of rebased branches being force-pushed to your bare repo by mistake, consider enabling the reflog in that bare repo (reflog is disabled by default when a bare repo is initialized). You can do this by running the git config --local --add core.logAllRefUpdates true in your bare repository. As a result, all "drastic" movements of heads in this repository will be logged as they do in "normal" repositories, and their original positions could be recovered. Note that in exchange you get potentially more disk space wasting in your bare repository. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
