Ralf Wildenhues <[EMAIL PROTECTED]> writes: > Hi Jim, all, > > in a recent commit you write > > | * HACKING: describe how to find a misplaced change-set > > | --- a/HACKING > | +++ b/HACKING > | @@ -360,6 +360,22 @@ Miscellaneous useful git commands > | you an interface with which you can reorder and modify arbitrary > | change sets on that branch. > | > | + * if you "misplace" a change set, i.e., via git reset --hard ..., so that > | + it's no longer reachable by any branch, you can use "git fsck" to find > | + its SHA1 and then tag it or cherry-pick it onto an existing branch. > | + For example, run this: > | + git fsck --lost-found HEAD && cd .git/lost-found/commit \ > | + && for i in *; do git show $i|grep SOME_IDENTIFYING_STRING \ > | + && echo $i; done > | + The "git fsck ..." command creates the .git/lost-found/... hierarchy > | + listing all unreachable objects. Then the for loop > | + print SHA1s for commits that match via log or patch. > [...] > > Using 'git fsck' for this purpose may be fine, but it is unnecessarily > expensive. In this special case, the 'git reflog' output will lead you > to the dangling commit right away, without any searching or guessing.
If the commit is still in the reflog then git fsck wouldn't consider it dangling anyway (without --no-reflogs). Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
