Re: Tracking file metadata in git -- fix metastore or enhance git?

[johnnyutahh <git.nabble.com@johnnyutahh.com>]

Following up on 
http://git.661346.n2.nabble.com/Tracking-file-metadata-in-git-fix-metastore-or-enhance-git-td6251248.html
this discussion re: git file-metadata-management , posted this:

http://superuser.com/questions/367729/how-to-reuse-extend-etckeepers-metadata-engine-for-git-control-of-non-etc-file

Any further movement on this topic?



Jonathan Nieder-2 wrote
> 
> Hi again,
> 
> Not sure if my thoughts will be useful here since you dropped me from
> the cc list.  But anyway:
> 
> Richard Hartmann wrote:
> 
>> here are the three options:
>>
>> 1) fix metastore
>> 2) default to gitperms
>> 3) extend git
>>
>> I still think 3) would be best, but someone would need to step up to
>> do this. Is anyone up for this task? If not, we will have to resort to
>> 1) or 2)
> 
> The usual practice in git development is
> 
>  (1) people make scripts wrapping plumbing commands (see git(1)) that
>      work well for themselves
>  (2) they tell the git list about it and publish it
>  (3) an idea emerges that this is suitable for inclusion, and it
>      gets included
> 
> In particular, git's design is not so monolithic --- "extend git" can
> mean "add a script" or "add a builtin" so it is not so involved as you
> seem to think.  See also contrib/README for a place to stop on the
> way.
> 
> Anyway, if you want something the just works, my suggestion is (4) use
> the hook scripts from etckeeper.  Last time I looked into this they
> worked better than metastore.
> 
> Hope that helps.
> Jonathan
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@.kernel
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


--
View this message in context: http://git.661346.n2.nabble.com/Tracking-file-metadata-in-git-fix-metastore-or-enhance-git-tp6251248p7092383.html
Sent from the git mailing list archive at Nabble.com.