8

Is there a way to push the reflog to a remote? This seems like it would be an incredibly useful thing to do, but I do not know of a way to do it. I'm envisioning something like git push --include-reflogs

In the end, I would want the remote to have a verbatim copy of the reflogs at the time of the push.

I tried using --mirror, but 1) I don't want to delete any branches from this particular remote except manually, 2) it still didn't copy the reflogs over to the remote.

Does anyone know if/how this can be done?

Rob Bednark
  • 25,981
  • 23
  • 80
  • 125
Alexander Bird
  • 38,679
  • 42
  • 124
  • 159
  • `git reflog` shows the changes of the tips of branches. Since Git is a DVCS, those changes will be different in different repositories. I'm not sure how you envision those being pushed. Would they overwrite the remote reflogs? – Klas Mellbourn May 30 '13 at 17:49
  • The purpose is for backups. If my HDD dies, I still have my reflog so that I can have as close of an exact state as it was on the last push. – Alexander Bird May 30 '13 at 21:01
  • That is what HDD backups are for! – NightOwl888 Oct 07 '13 at 13:39

3 Answers3

10

What you are really asking is, is there a way push around anonymous (that is, unreferenced) commit objects and their trees and blobs for backup purposes. Answer is no. Anonymous objects--objects that are only referenced by your reflog--are private to the local repo.

But--You can just copy the .git directory of any repo to do what you want. If the source repo is busy (e.g. commits are happening, or a garbage collection or a repack) at the time then you need to copy files and directories in the .git directory in a certain order. This is explained in various places but one example is http://article.gmane.org/gmane.comp.version-control.git/147354 ('If you want your rsync backup to be fine, you need to follow some ordering....')

Yawar
  • 11,272
  • 4
  • 48
  • 80
3

You can backup .git/logs which will backup the references to the commits (but not the commits or files themselves).

Actually, git stores reflog information under .git/log directory, you can do anything to them like open files in this directory with a text editor. If you remove this directory, all reflog disappears and if you recover it, the reflog will be back.

As far as I know, there is no builtin way to track the .git/logs. I have tried to move .git/log to working directory and make a symlink from .git directory to it. It works but not very well, because every time you do a commit, the HEAD moves and the .git/logs/HEAD changes, then you have a uncommited change now. The working directory will never be clean.

Rob Bednark
  • 25,981
  • 23
  • 80
  • 125
dyng
  • 2,854
  • 21
  • 24
  • -1: `.git/logs` directory contains only *references* to commits, not the commits or files themselves. Backing up only this dir makes the same sense as backing up desktop shortcuts. Reflog keeps references (hence the name) to commits that were HEAD in the recent past so they don't became unreferenced (dangling) and then garbage collected. And even if you don't have a reflog, you have a chance to restore lost commits via `git fsck` if they weren't GC'ed yet. You can find the details in Pro Git: http://git-scm.com/book/en/v2/Git-Internals-Maintenance-and-Data-Recovery – user Mar 30 '15 at 12:44
  • @user Backing up shortcuts is not something evil, what OP needs is exactly backing up shortcuts but not commits (which has been done by git). And reflog is not designed for preventing commits from unreferenced, because you can find them in ancestry tree of current HEAD or branch head, it's just a *log*. – dyng Mar 31 '15 at 01:24
  • Copying shortcuts without the objects that they point to makes no sense. Git pushes only those objects that are reachable from branches. You're missing the whole point of reflog: to make objects reachable for limited time after they were dropped from available branches. And those dangling objects do not go to the server, since they don't belong to any branch. – user Mar 31 '15 at 02:13
  • @user I have got your point and agree on what you said that reflog makes objects reachable after they are accidentally dropped (it saved me many times), but I also use reflog as a checkout history and thought it was what OP meant (maybe it's not true). But for both of two usage, I agree that a full copy of `.git` may be better. – dyng Mar 31 '15 at 03:12
0

Git reflog tracks HEAD changes of a single Git repository. Each clone has its own reflog. I can't figure out what you would do with a shared reflog (help someone remotely ?)

If you really need to track someone's reflog, you could dump the reflog content in a file using git reflog > dev1_reflog.txt and share dev1_reflog.txt (using git add dev1_reflog.txt; git commit -m "Adding dev1_reflog"; git push).

Guillaume Darmont
  • 5,002
  • 1
  • 23
  • 35