From: Michael J Gruber <git@drmicha.warpmail.net>
To: Kristian Amlie <kristian.amlie@trolltech.com>
Cc: git <git@vger.kernel.org>
Subject: Re: Honoring a checked out gitattributes file
Date: Wed, 28 Jan 2009 17:44:03 +0100 [thread overview]
Message-ID: <49808B53.6040907@drmicha.warpmail.net> (raw)
In-Reply-To: <498078F1.20807@trolltech.com>
Kristian Amlie venit, vidit, dixit 28.01.2009 16:25:
> Hi!
>
> We currently use msysGit in our company test farm to checkout the latest
> development branch and do autotests. However, we have one problem:
> Certain files require UNIX line endings, even though this is a Windows
> system. For this we use .gitattributes.
>
> However, if the .gitattributes file is also checked in to the branch, it
> will not always be honored. I browsed the code a bit, and it seems to
> happen whenever there is an existing .gitattributes file, but the
> checkout adds new files to it. These new files will not get the correct
> line endings (although I'm not sure if it happens *every* time, it could
> depend on the order they are checked out).
>
> I think this should be fairly straightforward to fix, by ensuring that
> if there is a file called .gitattributes in the index of the current
> directory, check it out first, before all the other files that may be
> affected by it. I can produce a patch and testcase for it, but I wanted
> to hear the opinions of some developers in case there is an obvious flaw
> in my solution.
>
> What do you think?
I think there's a general time ordering problem. Say you do the
following commits:
A: add a.txt
B: add a .gitattributes file covering *.txt (say with crlf or any filter)
C: add c.txt
Now, with an empty dir, you do either
1) checkout A, B, C sequentially
2) checkout C
The contents of the checkout will be different in cases 1) and 2):
1) a.txt is checked out out as is, c.txt according to the attributes
2) with current git: probably like 1), with your suggestion: both a.txt
and c.txt filtered according to the attributes.
If you add a file and .gitattributes covering it in the same commit
there is an ordering ambiguity which can be solved (patched away)
easily, but I think the difference between 1) and 2) is still
problematic, and would need to be dealt with.
The main problem seems to be that changing a file like gitattributes can
potentially change (by changing filters) the contents which should be
stored for a different file even if the checkout of that file doesn't
change.
Cheers,
Michael
next prev parent reply other threads:[~2009-01-28 16:45 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-28 15:25 Honoring a checked out gitattributes file Kristian Amlie
2009-01-28 16:44 ` Michael J Gruber [this message]
2009-01-28 17:25 ` Kristian Amlie
2009-01-30 13:00 ` Kristian Amlie
2009-01-30 13:00 ` [PATCH] Add a test for checking whether gitattributes is honored by checkout Kristian Amlie
2009-03-12 9:36 ` Honoring a checked out gitattributes file Kristian Amlie
2009-03-12 9:36 ` [PATCH 1/2] Add a test for checking whether gitattributes is honored by checkout Kristian Amlie
2009-03-12 9:36 ` [PATCH 2/2] Make Git respect changes to .gitattributes during checkout Kristian Amlie
2009-03-12 9:59 ` Johannes Sixt
2009-03-12 10:23 ` Kristian Amlie
2009-03-13 13:24 ` Honoring a checked out gitattributes file Kristian Amlie
2009-03-13 13:24 ` [PATCH 1/2] Add a test for checking whether gitattributes is honored by checkout Kristian Amlie
2009-03-13 13:24 ` [PATCH 2/2] Make Git respect changes to .gitattributes during checkout Kristian Amlie
2009-03-14 4:17 ` Junio C Hamano
2009-03-19 15:42 ` Kristian Amlie
2009-03-19 21:06 ` Junio C Hamano
2009-03-20 8:11 ` Kristian Amlie
2009-03-20 9:32 ` [PATCH] Add a test for checking whether gitattributes is honored by checkout Kristian Amlie
2009-03-14 4:36 ` [PATCH 1/2] " Junio C Hamano
2009-03-12 9:47 ` Matthieu Moy
2009-03-12 9:53 ` Kristian Amlie
2009-01-28 17:55 ` Honoring a checked out gitattributes file Jeff King
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49808B53.6040907@drmicha.warpmail.net \
--to=git@drmicha.warpmail.net \
--cc=git@vger.kernel.org \
--cc=kristian.amlie@trolltech.com \
/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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.