Nicolas Pitre wrote:
On Tue, 11 Sep 2007, Andreas Ericsson wrote:
So how does one unpack a packfile to extract the loose objects?
mv .git/objects/pack/*.pack /tmp/git-packs
for p in /tmp/git-packs/*.pack; do git unpack-objects < $p; done
?
Seems like an awful lot of trouble. I'll look into patching
builtin-pack-objects.c instead to accept an "--ignore-reflog" flag and prune
reflog-accessible objects. Will that break anything fundamental?
Why would you want to extract loose objects in the first place? That
appears to be a really funny goal to me.
I didn't. I wanted to get rid of superfluous loose objects in the odb.
If you want to retrieve a lost branch tip, it is certainly not an old
one, otherwise you'd certainly have forgotten about it. So why not
simply consulting the reflog, which, incidentally, was designed exactly
for that usage scenario, i.e. retrieving lost branches? It is certainly
easier than wadding through a pile of random loose commits.
So maybe we should deprecate git-lost-found? Since that was *also* designed
for the scenario where one has lost a branch tip.
Anyways, in this case the lost tip was the result of a git rebase, of which
there are usually 20 or so every day in my reflog. I knew what the commit-
subject was (roughly), but had no idea which of the 8 straight rebases that
got lost.
To me, the ability to say "HEAD@{35}" (or "HEAD@{650}"...) is not
fundamental,
Maybe it should?
Why? I'd have no idea where I'd end up. I can't remember exactly what I
did to my branch head more than 5 revs (or 15 minutes) ago, and since
the reflog provides "subject-by-action" instead of "subject-by-commit"
it's, imo, much less usable for recovering lost branch-heads.
and I don't know any scripts that rely on it for their
operations.
This is not meant to be used by script as much as users.
I'd suggest you simply try:
git reflog
and see how it should be much easier to find what you might have lost
that way.
Not really. It's cluttered to uselessness with "switched from branch
foo to branch bar" "rebase" (without commit-subject) and "merge x:
fast forward".
Had I only remembered the exact wording in the commit-subject I'd
have found it a lot faster with "git-lost-found | grep wording" than
I would have if I'd used the reflog from the start.
Since I (usually) meticulously store lightweight tags everywhere I
think there's a risk I'll need it, and also prune regularly, I
simply expected git-lost-found to be a little less verbose.
I had forgotten that the reflog protects the otherwise prunable
objects, which, in combination with my unwise usage of this particular
repo as an educational toy-repo landed me with a serious bunch of
loose tips.
Anyways, problem solved now. I'll just expire the reflog before I prune
and continue to use git-lost-found to recover loose tips when I need it.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
