On Mon, Aug 27, 2007 at 17:07:34 +0000, Sergio Callegari wrote:
> David Kastrup <dak <at> gnu.org> writes:
> 
> > 
> > Sergio Callegari <scallegari <at> arces.unibo.it> writes:
> > 
> > > 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 <bulb@ucw.cz>