git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Dmitry Kakurin" <dmitry.kakurin@gmail.com>
To: "Petr Baudis" <pasky@suse.cz>
Cc: "Git Mailing List" <git@vger.kernel.org>
Subject: .gitignore, .gitattributes, .gitmodules, .gitprecious?,.gitacls? etc.
Date: Mon, 27 Aug 2007 13:27:48 -0700	[thread overview]
Message-ID: <a1bbc6950708271327x4dd948d4m8e9e35f757a7d92e@mail.gmail.com> (raw)
In-Reply-To: <4C603F7C51884DF8AFAEC3F6E263798D@ntdev.corp.microsoft.com>

----- Original Message -----
From: "Petr Baudis" <pasky@suse.cz>
> On Sun, Aug 26, 2007 at 10:02:50AM CEST, Dmitry Kakurin wrote:
>>>> My knowledge of Git internals is quite limited, but if *I* were to do
>>>> it right now, I'd introduce a META entry in every TREE object that
>>>> would point to a BLOB that contains combined content of
>>>> .gitattributes, .gitignore etc.
>>> A tree that has .gitattributes (and I am assuming in the longer
>>> term you can use "ignore" and "precious" in .gitattributes
>>> instead of using .gitignore) POINTS TO A BLOB already, so what
>>> you are saying does not add anything to what we already have,
>>> other than that you are renaming .gitattributes to "META ENTRY".
>>
>> Almost true! The difference is: META BLOBS are not created as files in the
>> workspace (not during checkout, not ever).
>> In order to edit it you'd have to use 'git meta' command.
>> So once again, there is only one place to check for metadata - the index.
>
> It's still not clear to me how this would help anything, though I didn't
> watch late Git development. Can you explain some particular scenario
> where this would improve the current situation?

Here is the problem: we need to apply crlf attributes to a file. We
could have .gitattributes both in the index and in the worktree.
Which one do we use?
In general .gitattributes file could be (U)nchanged, (C)hanged, (NP)
NotPresent in each place.
This gives us 3x3 matrix = 9 special cases to handle. When you think
about this a little more you realize that even that
is not enough and we need to take into account direction of data
movement (index -> filesystem or vice versa).
This doubles the matrix to 18 cases. Even if we come up with a very
good choice for every case (which is doubtful)
there is no way this could be *easily* explained to end user, or even memorized.
This leads to a simple idea that mostly works:
1. when files are moved from index to filesystem, then only
.gitattributes in the index is used, if it's not there == no special
attributes.
2. when files are moved from filesystem to index, then only
.gitattributes in filesystem is used, again if it's not there == no
special attributes.

Then, in any operation, only one .gitattributes is taken into account.
We could stop here, but to me this redundancy still has some room for
confusion and looks unnecessary.
Plus there is still room for unintentional abuse (by mistake).

That's why I think it's a good idea to always have only one .gitattributes.

- Dmitry

  parent reply	other threads:[~2007-08-27 20:28 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-26  2:59 .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc Dmitry Kakurin
2007-08-26  4:37 ` Junio C Hamano
2007-08-26  5:17   ` Dmitry Kakurin
2007-08-26  5:33     ` Junio C Hamano
2007-08-26  6:36       ` Dmitry Kakurin
2007-08-26  7:28         ` Junio C Hamano
2007-08-26  8:02           ` Dmitry Kakurin
2007-08-26 10:06             ` Petr Baudis
     [not found]               ` <4C603F7C51884DF8AFAEC3F6E263798D@ntdev.corp.microsoft.com>
2007-08-27 20:27                 ` Dmitry Kakurin [this message]
     [not found]                   ` <Pine.LNX.4.64.0708280945350.28586@racer.site>
2007-09-04 20:23                     ` .gitignore, .gitattributes, .gitmodules, .gitprecious?,.gitacls? etc Jan Hudec
2007-09-05  8:06                       ` Dmitry Kakurin
2007-09-05  8:14                         ` Junio C Hamano
2007-09-05  8:31                           ` Dmitry Kakurin
2007-09-05 18:38                           ` Jan Hudec
2007-08-27  2:51             ` .gitignore, .gitattributes, .gitmodules, .gitprecious?, .gitacls? etc Sam Vilain
2007-08-27  5:52               ` David Kastrup
2007-08-27 10:56                 ` Sam Vilain
2007-08-27 11:26                   ` David Kastrup
2007-08-27 11:30                   ` Johannes Schindelin
     [not found]                     ` <46D33A15.1000003@vilain.net>
     [not found]                       ` <Pine.LNX.4.64.0708280942360.28586@racer.site>
     [not found]                         ` <46D4A4F8.9040004@vilain.net>
     [not found]                           ` <Pine.LNX.4.64.0708290007020.28586@racer.site>
2007-09-04 20:49                             ` Jan Hudec
2007-08-26 15:05     ` Johannes Schindelin
2007-08-27 11:35   ` martin f krafft
2007-08-27 15:34   ` Sergio Callegari
2007-08-27 15:48     ` David Kastrup
2007-08-27 16:54       ` Petr Baudis
2007-08-27 17:22         ` Sergio Callegari
2007-08-27 17:07       ` Sergio Callegari
2007-09-04 21:03         ` Jan Hudec

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a1bbc6950708271327x4dd948d4m8e9e35f757a7d92e@mail.gmail.com \
    --to=dmitry.kakurin@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=pasky@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).