[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: finding misplaced changes with git
From: |
Andreas Schwab |
Subject: |
Re: finding misplaced changes with git |
Date: |
Tue, 22 Jul 2008 10:13:40 +0200 |
User-agent: |
Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) |
Ralf Wildenhues <address@hidden> 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, address@hidden
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."