Nicolas Pitre wrote:
quoted text
> 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.

quoted text
> 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.

quoted text
>> 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.

quoted text
>> 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@op5.se
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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html