Re: git: avoiding merges, rebasing

[Benoit SIGOURE]

On Oct 2, 2007, at 1:50 PM, Bruno Haible wrote:

Hello Benoit,

    $ git stash
    $ git pull
    $ git stash apply
    $ git stash clean              ; typo!
    $ git stash clear              ; fatal correction to typo!

and lost 20 modified files. Well, not really lost. Just took me a
while to

I don't really see how and why you "lost 20 modified files".

into a stash named "clean", and "git stash clear" killed it.

I lost modifications to 20 files. "git stash clean" moved these modifications

Ahh I see. That's very tricky indeed. Maybe git-stash should warn when you create a stash named `clean'.

Is there some shorthand for this process, such as a "git-recover"
command?

you can run git fsck and look for
a dangling commit (which can be inspected with git show <sha1>) where
you are most likely to find your stash (unless you run git-gc or this
sort of thing).

page or in an FAQ. It can be a real life-saver.

Cool! This information would be worth mentioning in the git-stash manual

True.  Propose a patch :-)

Someone just told me on IRC that you can also use git lost-found
(which worked for me).

"git lost-found" does not work well for me: I stopped it after it ate
10 minutes of CPU time without producing a result. If you think that's
a bug (endless loop?), you can find the repository I was working on at
  http://www.haible.de/bruno/gnulib-testgit.tar.gz

Cheers,

--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory

Works for me with git version 1.5.3.3.131.gb63f4. fsck can be quite long, it took roughly 3 minutes on my Core2Duo 2Ghz (although I think that it's not threaded so the fact I have a 2nd core is probably not relevant here). On IRC ([EMAIL PROTECTED]) someone pointed out that if fsck takes too much time, it might be time to repack. This seems to be true for most git commands. Your .git is 30M, after a git gc -- prune --aggressive it shrunk down to 13M.

PGP.sig
Description: This is a digitally signed message part