bug-coreutils
[Top][All Lists]
Advanced

[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."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]