It's not a bug, it's an undocumented feature. It should be documented as 
"git-unpack-objects < $pack; rm $pack" is something one would deem correct at 
first glance (luckily I just moved the pack away and did git-fsck-cache).

To write an object, git-unpack-objects ends in

unpack-objects.c:write_object -> sha1_file.c:write_sha1_file:

        /* Normally if we have it in the pack then we do not bother writing
         * it out into .git/objects/??/?{38} file.
         */

This indeed works, so the files aren't unpacked.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it
-

[ message continues ]

Funny, I just did the exact same thing today, scratched my head and
said ``what did I just do!?!?!'' as I had deleted the pack before
discovering that nothing was actually unpacked.  *sigh* At least
it was a clone of the real repository and thus didn't matter to me.

I totally didn't expect that behavior.  But I should have.  It makes
perfect sense.

-- 
Shawn.
-

[ message continues ]

Good to hear that you two did not lose any data.  I think the
command should be documented as "not for interactive use without
understanding what it does" ;-).

What was the reason you wanted to use it?  I think we should
have a wrapper command to do what you wanted to achieve, so that
people do not have to run unpack-objects by hand.

One thing I _could_ think of is to explode a contaminated pack
so that you can repack.  For example, every time I do "git
repack -a -d", the resulting pack ends up containing a couple of
commits from my "pu" branch that will become dangling when I
redo "pu" the next time.  But then "git repack -a -d" is so
inexpensive these days, without unpacking things first, I do not
see the point of exploding a pack using unpack-objects in the
first place.


-

[ message continues ]

Don't bother.

I wanted to explode a pack because I'm starting work on an Eclipse
plugin for GIT.  I thought I'd try going down the road of letting
the plugin read the repository directly, and write loose objects
directly, but leave pack construction to the native C code.  So I
tried to clone my local GIT repository to a new directory (thus
had no loose objects at all) and unpack it to get loose objects.
That didn't go so well.  :-)

So now I'm currently just playing around with a tiny repository I
created for testing (something like 50 objects total).  Since I have
never packed it everything is loose, and that's working out OK...

I've already got loose object reading working, but thanks to
the trivially simple repository format in GIT (thanks Linus,
et.al.!) that amounted to a trivial Java implementation so its
nothing to really brag about yet.  :-)

-- 
Shawn.
-

[ message continues ]

Before "git-repack -a" was invented, I used to do this by hand:

	$ mkdir ./++preserve
        $ mv .git/objects/pack/pack-*.pack ./++preserve
        $ for p in ./++preserve/pack-*.pack
          do git-unpack-objects <$p; done

-

[ message continues ]