Re: repack: handling of .keep files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"Alex Riesen" <raa.lkml@xxxxxxxxx> writes:

> Still, git-log shouldn't crash (nothing should, of course).

Honestly, I think that's borderline.  If you "dd if=/dev/random
of=/dev/hda", should the kernel keep going, perhaps gracefully
declining access to the filesystem on that drive?

> And, the temporary pack is created in working tree, instead of in GIT_DIR
> (why not GIT_OBJECT_DIR, btw?)

Not limited to the temporary pack (the detail of exact use
pattern escapes me -- I do not think it was temporary pack that
initiated the use of GIT_DIR for temporary things), I think
trying to not create things in the working tree came after
somebody who had a read-only (to him, not necessarily to
everybody) working tree and read-write GIT_DIR (separate
location, specified with the environment variable) had trouble.
At least the theory was GIT_DIR would be writable as long as you
are doing a "write" oriented operation, regardless of what.

Back then we did not support working in subdirectory of the
project as fully as we do now, so using such configuration was
not much less convenient than you have the normal layout of
having $project/.git directory at the top of the working tree.

While I do not think it is worth to try "supporting" use of
read-only working tree for write oriented operations, which
means that it should be safe to assume that the working tree is
writable and we _could_ create temporary pack in working tree
instead, I do not think the "_could_" means we should.  In the
case of temporary pack I do not think there would be a risk of
filename collisions, I think it makes sense to use either
GIT_DIR or GIT_OBJECT_DIRECTORY instead of the working tree.  

I do not know pros-and-cons between .git/ and .git/objects/;
filesystems tend to cluster nearby things better, so the latter
might be more logical, but packs are about using smaller (much
much much smaller) number of files than you would use otherwise
to store objects _and_ keeping them in use, so I suspect it
would not make much practical difference even if we try to
encourage the filesystem to allocate the disk blocks for new
pack near existing packs by creating the temporary file.


-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]