Thread (10 messages) flat view 10 messages, 8 authors, 2016-06-15

Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc.

From: Jan Hudec <hidden>
Date: 2016-06-15 22:43:33

On Mon, Aug 27, 2007 at 17:07:34 +0000, Sergio Callegari wrote:
David Kastrup <dak <at> gnu.org> writes:
quoted
Sergio Callegari <scallegari <at> arces.unibo.it> writes:
quoted
Couldn't all this directory/ownership/permission tracing be easily
done by using hooks?  E.g. Having a pre-status and pre-commit hook
one could fire up a program/script to collect all the extra info he
wants to trace and store it somewhere (typically in some traced
file).  The other way round one could have a post-checkout hook and
he could arrange it to fire up some program to look into the
extra-info file to set up all the meta-data he wants.

This would be very flexible and would permit to manage absolutely
/any/ kind of the metadata leaving absolute freedom about how to do
so.

Am I missing something here?
Merging.
Sorry, maybe I am really missing something, since merging does not look to me
as an issue.

Why cannot git simply do the merging in the working tree as it normally
does, including merging of the traced metadata file generated by the metadata
helpers invoked via the hooks?
Only, again more hooks are needed and likely a post-merge hook, so that at
the end of the merge, the metadata can be applied.

Only, to have things going on smoothly, one should be so wise to assure that
the metadata helpers save metadata as nice, sorted text files in order to
minimize the burden of manual intervention if there are conflicts in
metadata merging.
The post-checkout (no need for post-merge -- after in-index merge is done,
the files are checked out to worktree, so post-checkout would run anyway)
could actually apply any custom merge strategy required to avoid/clean up
spurious conflicts in the metadata file (eg. adding two files that go after
each other would be a textual conflict). The relevant versions are stored in
index stages at that point.
BTW.  Having a post-checkout hook could also help getting rid of unwanted
empty directories, couldn't it?
Probably not. I would imagine it would actually only run for the files being
checked out -- and there is nothing checked out in empty directories. (Well,
it would run once or once per directory with list of checked out files on
standard input).

-- 
						 Jan 'Bulb' Hudec [off-list ref]

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help