{"thread":{"id":"4846","subject":"Reflog support status","startedAt":"2006-07-11T06:34:35Z","lastAt":"2006-07-11T06:34:35Z","messageCount":1,"participants":["Shawn Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"23619","messageId":"20060711063435.GD11822@spearce.org","threadId":"4846","inReplyTo":null,"subject":"Reflog support status","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-07-11T06:34:35Z","receivedAt":"2006-07-11T06:34:35Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"My recent flurry of patches tonight (looks to be 5 total, 6\ncounting the user.name/user.email bug fix) should now include\nreasonably useful information messages anytime a ref which has an\nassociated reflog gets updated, unless the update was made by one\nof the following:\n\n\tgit-archimport\n\tgit-cvsimport\n\tgit-svnimport\n\tgit-receive-pack\n\nWhich is pretty reasonable.\n\nI'll try to tackle git-receive-pack tomorrow night, but the reason\nI have been putting it off is it would die a horrible death (exit\nanyway) if it attempts to update a logged ref and GIT_COMMITTER_IDENT\ncan't be determined.  But if the repository owner has enabled\nreflogging exiting is probably the right thing to do in that case...\n\nI'd also like to parameterize git-am's reflog entries the way I\ndid with git-merge, this way git-rebase will report as 'rebase'\nin the log rather than 'am'.  Again, I'll see if I can get that\ndone tomorrow night.\n\nJunio: do you happen to still have that reflog program you put\ntogether?  I'm wondering if maybe we shouldn't include a git-reflog\nto cat the reflog file in a more human friendly format than the\ntimestamps contained within the file, not to mention maybe also do\noneline commit pretty printing.\n\n-- \nShawn.\n"}]}