patchAdd exclude file support to cg-status

Adds a trivial per-repository exclude file implementation for cg-status on top of the new git-ls-files option.

Signed-off-by: Matt Porter <mporter@kernel.crashing.org>

--- 002c6f1e4924965e2101d2e6447855f10c55df41/cg-status (mode:100755 sha1:9e7f0e59284a3d15cda35bbd5579c44d8eda05d5) +++ 1b8c5395679e5c04734b1c86445a6355124ada7e/cg-status (mode:100755 sha1:6669e36f5ff5d5964882b58ba43a5dcab4fd7fc6)

MP> Adds a trivial per-repository exclude file implementation for MP> cg-status on top of the new git-ls-files option.

 
MP> +EXCLUDEFILE=.git/exclude

Good intentions, but shouldn't the file be .git/info/exclude (i.e. under .git/info)?

On Mon, May 02, 2005 at 06:09:19PM -0700, Junio C Hamano wrote:

My reasoning for not doing something like this was that there is only ever one exclude file. In other instances of cogito specific data in the .git directory, there is a subdir named for the class of data being stored there (i.e. branches, refs). In this case, it didn't seem necessary. On the other hand, this made me wonder whether there should just be a .git/cginfo subdir where exclude, branches, refs, etc. all live under since they are cogito specfic functionality. Something like:

.git/cginfo/

	    exclude
	    branches/
	    refs/

and so on...

-Matt

MP> My reasoning for not doing something like this was that there is MP> only ever one exclude file. In other instances of cogito specific MP> data in the .git directory, there is a subdir named for the class MP> of data being stored there (i.e. branches, refs). In this case, MP> it didn't seem necessary. On the other hand, this made me MP> wonder whether there should just be a .git/cginfo subdir where MP> exclude, branches, refs, etc. all live under since they are MP> cogito specfic functionality. Something like:

MP> .git/cginfo/

MP> exclude MP> branches/ MP> refs/

MP> and so on...

You may want to check the past thread, like this one:

    From: Daniel Barkalow <barkalow@iabervon.org>
    To: Junio C Hamano <junkio@cox.net>
    cc: David Greaves <david@dgreaves.com>, 
        GIT Mailing Lists <git@vger.kernel.org>
    Subject: Re: [PATCh] jit-trackdown
    Message-ID: <Pine.LNX.4.21.0504291730000.30848-100000@iabervon.org>

    On Fri, 29 Apr 2005, Junio C Hamano wrote:

    > Have toilet side gitters reached a concensus (or semi-concensus)
    > on how things under .git/ should be organized?  Is there a
    > summary somewhere, something along the following lines?

    I've made a proposal like the following:

    .git/
      objects/    (traditional)
      refs/       Directories of hex SHA1 + newline files
        heads/    Commits which are heads of various sorts
        tags/     Tags, by the tag name (or some local renaming of it)
      info/       Other shared information
        remotes
      ...         Everything else isn't shared
      HEAD        Symlink to refs/heads/<something>

    The plumbing doesn't care what you name heads or tags, but expects things
    to be in heads to be commit objects and tags to be tag objects (which can
    tag whatever).

    AFAICT, there is general concensus that this is how things should be, but
    I haven't convinced Linus that the plumbing should know about anything
    other than objects/.

            -Daniel

On Mon, May 02, 2005 at 09:15:43PM -0700, Junio C Hamano wrote:

<snip>

Ok, I see I skimmed the archives way too fast after vacation. :)

I'll update the patch to match.

Thanks, Matt

On Mon, May 02, 2005 at 06:09:19PM -0700, Junio C Hamano wrote:

Ok, here is the updated version.

Signed-off-by: Matt Porter <mporter@kernel.crashing.org>

--- aa6233be6d1b8bf42797c409a7c23b50593afc99/cg-status (mode:100755 sha1:9e7f0e59284a3d15cda35bbd5579c44d8eda05d5) +++ d69eece260c0c4fcd53991c1b37ac91b99962681/cg-status (mode:100755 sha1:874504aa8cf9ab7076eb405e19995615b4f59eab)

Dear diary, on Tue, May 03, 2005 at 02:10:42AM CEST, I got a letter where Matt Porter <mporter@kernel.crashing.org> told me that...

Thanks, applied. I decided to go with this version instead of the .git/info/exclude one since I *don't* think you want to share this. The very fact it is in the .git/ directory implies here that these are your local exclude patterns which are likely temporary and more importantly you don't want them under version control. Therefore they aren't really interesting for anyone else and should be kept per-tree. That's this file's point as I view it. If you want something more persistent, get it to git's sight.

The fact that we have no support for version-tracked exclude file can't stop me! ;-)

PB> ... since I *don't* think you want to share this. The very PB> fact it is in the .git/ directory implies here that these PB> are your local exclude patterns which are likely PB> temporary...

Is it really the case? I recall that Linux kernel started shipping with the standard dontdiff file for everybody's use some time ago, after enough people wanted it included in the upstream release. Maybe you would want to read from both?

PB> The fact that we have no support for version-tracked exclude file can't PB> stop me! ;-)

What darcs folks do is that they have a per-tree configuration (kept in ./_darcs, which is similar to our ./.git) that says which file is the exclude list, and by setting configuration item to point at a file which _is_ version controlled they can share the exclude file.

Dear diary, on Mon, May 09, 2005 at 01:28:44AM CEST, I got a letter where Junio C Hamano <junkio@cox.net> told me that...

Of course. You should combine them both, the .git/ one having the ultimate precedence (if we support the CVS-like ! stuff too).

That is, in CVS the version-controlled files are per-directory, which can be very nice too; things are getting harder now, though, since we should have some per-project ignore file too.

That is certainly a good idea (at least for kernel, where you probably just want to give it dontdiff), but we need a sensible default.