On Sun, 16 Sep 2007, Junio C Hamano wrote:

quoted text
> I however think your idea to have extra "permission information
> file" is very interesting.  What would be more palatable, than
> mucking with the core level git, would be to have an external
> command that takes two tree object names that tells it what the
> old and new trees our work tree is switching between, and have
> that command to:
> 
>  - inspect the diff-tree output to find out what were checked
>    out and might need their permission information tweaked;
> 
>  - inspect the differences between the "permission information
>    file" in these trees to find out what were _not_ checked out,
>    but still need their permission information tweaked.
> 
>  - tweak whatever external information you are interested in
>    expressing in your "permission information file" in the work
>    tree for the paths it discovered in the above two steps.
>    This step may involve actions specific to projects and call
>    hook scripts with <path, info from "permission information
>    file" for that path> tuples to carry out the actual tweaking.

Why not have the command also responsible for creating the files that need 
to be created (calling back into git to read their contents)? That way, 
there's no window where they've been created without their metadata, and 
there's more that the core git doesn't have to worry about.

I could see the program getting the index, the target tree, and the 
directory to put files in, and being told to do the whole 2-way merge 
(except, perhaps, updating the index to match the tree, which git could do 
afterwards). As far as git would be concerned, it would mostly be like a 
bare repository.

	-Daniel
*This .sig left intentionally blank*
-
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