From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Hudec Subject: Re: .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc. Date: Tue, 4 Sep 2007 23:03:49 +0200 Message-ID: <20070904210349.GE3786@efreet.light.src> References: <2646CA4BEA644C9E9089C4A1AC395250@ntdev.corp.microsoft.com> <7v1wdqud0z.fsf@gitster.siamese.dyndns.org> <86odgtou5p.fsf@lola.quinscape.zz> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="AsxXAMtlQ5JHofzM" Cc: git@vger.kernel.org To: Sergio Callegari X-From: git-owner@vger.kernel.org Tue Sep 04 23:04:14 2007 Return-path: Envelope-to: gcvg-git@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1ISfZ1-0002EA-98 for gcvg-git@gmane.org; Tue, 04 Sep 2007 23:03:59 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754764AbXIDVDz (ORCPT ); Tue, 4 Sep 2007 17:03:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754404AbXIDVDz (ORCPT ); Tue, 4 Sep 2007 17:03:55 -0400 Received: from ns1.bluetone.cz ([212.158.128.13]:37116 "EHLO ns1.bluetone.cz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754608AbXIDVDy (ORCPT ); Tue, 4 Sep 2007 17:03:54 -0400 Received: from localhost (spamhole.bluetone.cz [192.168.13.2]) by ns1.bluetone.cz (Postfix) with ESMTP id 7B9F057264; Tue, 4 Sep 2007 23:03:53 +0200 (CEST) Received: from ns1.bluetone.cz ([192.168.13.1]) by localhost (spamhole.bluetone.cz [192.168.13.2]) (amavisd-new, port 10026) with ESMTP id 3QhCAkgZFpnq; Tue, 4 Sep 2007 23:03:50 +0200 (CEST) Received: from efreet.light.src (145-119-207-85.strcechy.adsl-llu.static.bluetone.cz [85.207.119.145]) by ns1.bluetone.cz (Postfix) with ESMTP id 9F73B57252; Tue, 4 Sep 2007 23:03:50 +0200 (CEST) Received: from bulb by efreet.light.src with local (Exim 4.67) (envelope-from ) id 1ISfYr-00054y-53; Tue, 04 Sep 2007 23:03:49 +0200 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.16 (2007-06-11) Sender: git-owner@vger.kernel.org Precedence: bulk X-Mailing-List: git@vger.kernel.org Archived-At: --AsxXAMtlQ5JHofzM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 27, 2007 at 17:07:34 +0000, Sergio Callegari wrote: > David Kastrup gnu.org> writes: >=20 > >=20 > > Sergio Callegari arces.unibo.it> writes: > >=20 > > > 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? > >=20 > > Merging. > >=20 >=20 > Sorry, maybe I am really missing something, since merging does not look t= o me > as an issue. >=20 > 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 meta= data > 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. >=20 > Only, to have things going on smoothly, one should be so wise to assure t= hat > 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). --=20 Jan 'Bulb' Hudec --AsxXAMtlQ5JHofzM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG3cg1Rel1vVwhjGURAgohAJ4zt6qwBx4HTQecdksbIHxZTRvPPgCfcB/i 4llyGZyW5bUbVFDsZr6ehlE= =pG8A -----END PGP SIGNATURE----- --AsxXAMtlQ5JHofzM--