git-reflog

问题 I tend to be a bit paranoid about my data, including the ability to recover it. Git reflog data is pruned after 30 days. Is there a way of setting it so that the reflog data is maintained and kept indefinitely? Any major advantage or disadvantage (other than space or speed considerations) to doing so? 回答1: Caveat: reflogs are local and are not sent/received with push/pull operations. Cons: reflogs may result in (otherwise) unreachable snapshots (and consequently blobs) being kept around,

问题 This question already has an answer here : git log shows skipped lines on my bash (1 answer) Closed 3 years ago . After reading here as far as I have learned git reflog will show a list of all heads, basically it will keep a history after every checkout you do. Right? What I don't understand is why are there long empty spaces between the list of heads? Also between lines I see :...skipping... What is that? See the output of my git reflog git reflog 7136d2c HEAD@{0}: checkout: moving from

问题 The git-reflog command doesn't by default show a date alongside each entry, which strikes me as a strange oversight; I think this would be very helpful. Are there any command-line options, or other tweaks, which can be employed to cause it to show when each reflog entry was added? The manpage isn't forthcoming... 回答1: As the man page writes you can use the options for git log , say git reflog --pretty=short or any other as you like try git reflog --date=iso 回答2: You can use the --walk-reflogs

问题 I added some files to the index but then by mistake I deleted them with git reset --hard . How do I recover them? Here's what happened: I added all files using git add . I then committed When I checked the status, there were still files that weren't included in the commit from the add, which was strange I added the untracked files again and it worked this time But I wanted everything to be in 1 single commit so I looked up how to unstage what I just committed I used git reset --hard HEAD^ —

问题 After a lot of rebasing a repository to our latest needs our reflog is full of commits and orphan branches. We reached the final state of our reorganization. While there're branches and commits left with a lot of binary data the repository grew multiple times of its origin size we decided to purge all the old reflog entries and data. I was digging in the manual but didn't get much smarter experimenting with git-reflog expire This is an example of the log (shortened) -> <sha1> [development] ..

问题 I previously asked this but I closed it as it was a close duplicate of the same issue with git log . Now I have a similar question that why does git reflog show 'different lists of HEAD logs'? If I use keyboard to go down I see from HEAD0 all the way to HEAD 247 which is where I clone d my repo. which sounds very logical and understandable YET I see another long list that is from HEAD 1 to HEAD 225 & then another that is from HEAD0 to HEAD 225 and then another that is from HEAD0 to HEAD 90.

问题 I do not have a specific problem at hand, but I have encountered in the past some cases where I accidentally blew up my index, and wished I could go back the the previous state of a given file, which was indexed at some point. Some example cases are : $ git add <file> # find out that I already had an indexed version of <file>, # and that for some reason I shouldn't have added the extra modifications $ git stash pop # find out afterwards that I have a mix of "the index I had" # and "the index

问题 I noticed in the documentation you can specify the parameter --grep-reflog --grep-reflog=<pattern> Limit the commits output to ones with reflog entries that match the specified pattern (regular expression). With more than one --grep-reflog, commits whose reflog message matches any of the given patterns are chosen. It is an error to use this option unless --walk-reflogs is in use. I kind of wanted clarification on how this is different from --grep . What benefit is there for looking through

问题 We are using throwaway integration branches which are pushed, and then later deleted and recreated. However the discarded branches are leaving dangling commits and trees which I can view with this command: git fsck --unreachable --no-reflogs I could clean them up with git reflog expire --expire-unreachable=now --all git gc --prune=now or something similar, but I want to understand the scope of these commands and related configuration first. So the specific questions: So that new clones are

问题 I have a repository for which a regular git reflog --date=iso shows a lot of entries, for example see this fragment https://gist.github.com/FreddieChopin/0206c9ef530a056c624b065eed048c9d As you may notice, there are reflogs for 19th, 22nd, 23rd, 24th, 25th and 26th of February. But if I would like to limit the output to certain dates, this doesn't work as expected. For example git reflog --date=iso --since="2017-02-20" gives only this https://gist.github.com/FreddieChopin