david@xxxxxxx writes: > git has pre-commit hooks that could be used to gather the permission > information and store it into a file. > > git now has the ability to define cusom merge strategies for specific > file types, which could be used to handle merges for the permission > files. > ... > There are some significant advantages of having the permission store > be just a text file. > > 1. it doesn't require a special API to a new datastore in git > > 2. when working in an environment that doesn't allow for implementing the > permissions (either a filesystem that can't store the permissions or > when not working as root so that you can't set the ownership) the file > can just be written and then edited with normal tools. > > 3. normal merge tools do a reasonable job of merging them. > > however to do this git would need to gain the ability to say 'this > filename is special, it must be checked out before any other file is > checked out' (either on a per-directory or per-repository level) I'd rather not implement it at such a low level where a true "checkout" happens. For one thing, I am afraid that the special casing will affect the normal codepath too much and would make it into a maintenance nightmare. But more importantly, if you are switching between commits (this includes switching branches, checking out a different commit to a detached HEAD, or pulling/merging updates your HEAD and updates your work tree), and the contents of a path does not change between the original commit and the switched-to commit, you may still have to "checkout" the external information for that path if your "permission information file" are different between these two commits. To the underlying checkout aka "two tree merge" operation, that kind of change is invisible and it should stay so for performance reasons, not to harm the normal operation. IOW, I do not want the core level to even know about the existence of "permission information file", even the code that implements it is well isolated, ifdefed out or made conditional based on some config variable. 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. If we go that route, I am not deeply opposed to add code to Porcelains to call that new command after they "checkout" a new commit at the very end of their processing (namely, git-commit, git-merge, git-am, and git-rebase). Yes, I am very well aware that somebody already mentioned "there is a window between the true checkout and permission tweaking". If you need to touch the core level in order to close that window, I am not interested. > The ability to handle /etc comes up every few months. it's got to be > the most common unimplemented request git has seen. Asking a pony for many times does not necessary make it the right for you to have the pony. The sane way to implement this is in your Makefile, as Randal and other people with more experience have already pointed out, and I happen to agree with them. My gut feeling is that the approach to use an external hook that reads your "permission information file" could be done with negligible impact to the normal operation of git. I suspect that the "new command" I suggested above that would run after "checkout" actions would perform what people need to do in their Makefiles' "install" rules (if they have the work tree vs target tree distinction), or "post-checkout" rules (if they want to use the work tree in-place), and not having to write/reinvent a Makefile target for this in every project would hopefully make it easier to use. That is the only reason I am writing this message on this topic. > so would changes like this be acceptable? That is a different question. Is having an extention to help people who want to manage perm bits a worthy goal? Perhaps, but it depends. Is it worthy enough goal to complicate the really core parts of the code and add huge maintenance burden? Absolutely not. Can it be made in such a way that it does not have much impact to the core parts? We need to see how it is done. - 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
