Re: [RFC PATCH] Re: Empty directories...

[Nix <nix@esperi.org.uk>]

On 23 Jul 2007, David Kastrup uttered the following:
> Nix <nix@esperi.org.uk> writes:
>> Actually, if we had a post-checkout hook, we could use a pre-commit
>> hook to keep track of directory existence, permissions, et seq, and
>> a post- checkout hook to restore them.
>
> Actually, tracking permissions would be cheap: one just needs to
> replace the permission-munging macros in git with identity.  Ownership
> -- well, that's harder.
>
> But my sentiment remains: git _tracks_ stuff: it notices when things
> move around and follows them.  Statically snapshotting permissions
> creates a layer that is quite less flexible.  The information gets
> detached.

Not if you record it in a file which is checked in in the same commit
that is tracked, it isn't (that's what the pre-commit hook is for). It's
true that git won't natively have any knowledge of that data, but Linus
has fairly effectively shown that it shouldn't have any such knowledge
and doesn't need it.

(You might want to give git-diff knowledge of it, just so it can skip
it unless a new flag is given. Give the file a nice format, and bingo,
readable permission/ownership diffs!)

(I'd recommend storing the names of user/group file owners as well as
the uids, so you can --- given suitable permissions --- chown to the
right username in preference to uid if that user exists at checkout
time.)


Doing this *efficiently* is another matter: probably a pair of hooks are
needed, run on pre-checkout and post-checkout: they can communicate so
as only to fiddle permissions on things which are newly appeared or
whose permissions have changed.

Obviously because the permissions, ownerships et al aren't recorded in
the index this will slow committing down, but given that
git-update-index will already have sucked the entire tree's inodes into
the page cache anyway, I don't think a second pass over the working tree
snarfing permissions would slow it down much.


As I need this anyway (I'm backing up a filesystem via git, yes, I'm
insane but I need version control and it's horrifically redundant so
packing it will save heaps of space), I guess I'd better get off my
rear and write the code.

(The recent commit-as-a-builtin's introduction of a run_hook() function
will be pretty damn useful: good timing, I guess.)