All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steffen Prohaska <prohaska@zib.de>
To: unlisted-recipients:; (no To-header on input)
Cc: git@vger.kernel.org, Steffen Prohaska <prohaska@zib.de>
Subject: .gittattributes handling has deficiencies
Date: Sun, 21 Oct 2007 10:48:55 +0200	[thread overview]
Message-ID: <1192956535617-git-send-email-prohaska@zib.de> (raw)

If a .gitattributes is in the work tree and we checkout a
different head, the .gitattributes of the head we are switching
to must have precedence. Files are expected to be converted as
configured in the .gitattributes that is available in the head
we're switching to.

This adds a test case revealing deficiencies of the current
handling of .gitattributes.

At a first glance, I saw two possible resolutions:
1) .gitattributes from the index has precedence. It's unclear
   how merging can be handled appropriately.
2) .gitattributes are handled as a special file. Checkout is a
   two pass process. In the first pass only the special file
   .gitattributes is checked out. In th second pass the remaining
   files are added. Maybe this gives a perspective how to handle
   merges.

But actually the issue is much harder to solve.

Here is what needs to be done: Whenever the attributes of a file
change the file must be freshly checked out according to the
attributes of the head we switch to. The file itself does not
necessarily change between the two commits. A fresh checkout is
already needed if only .gitattributes change.

But this is really hard to solve. We would need to compare
attributes before and after for _all_ files that have attributes
in one of the two commits and check if they changed. If so, we
need to do a fresh checkout according to the new attributes.

Maybe the gitattributes of a file should be part of the per-file
flags in the index. Thus we could verify if the flags changed and
if so, adjust the work tree accordig to the new flags.  I'm
lacking a deeper insight into the git internals.  Therefore, I
can't really say if the index is the right place.  But it looks
to me as if changing an attribute should be treated similar to a
changing sha1, as far as the work tree is concerned.

So, I need some help.
    Steffen

---
 t/t0020-crlf.sh |   23 +++++++++++++++++++++++
 1 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
index 62bc4bb..5d7e033 100755
--- a/t/t0020-crlf.sh
+++ b/t/t0020-crlf.sh
@@ -371,6 +371,29 @@ test_expect_success 'in-tree .gitattributes (4)' '
 	}
 '
 
+test_expect_success 'in-tree .gitattributes (5)' '
+
+	git reset --hard master &&
+	echo >.gitattributes &&
+	git add .gitattributes &&
+	git commit -m "empty .gitattributes" &&
+	rm -rf tmp one dir .gitattributes patch.file three &&
+	git reset --hard master &&
+	git checkout master^ &&
+
+	if remove_cr one >/dev/null
+	then
+		echo "Eh? one should not have CRLF"
+		false
+	else
+		: happy
+	fi &&
+	remove_cr three >/dev/null || {
+		echo "Eh? three should still have CRLF"
+		false
+	}
+'
+
 test_expect_success 'invalid .gitattributes (must not crash)' '
 
 	echo "three +crlf" >>.gitattributes &&
-- 
1.5.3.mingw.1.138.g7bf9d

             reply	other threads:[~2007-10-21  8:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-21  8:48 Steffen Prohaska [this message]
2007-10-21  9:19 ` .gittattributes handling has deficiencies david
2007-10-21 10:27   ` Steffen Prohaska
2007-10-21 17:09     ` david
2007-10-21 17:25       ` Steffen Prohaska
2007-10-21 17:57         ` david
2007-10-21 20:21           ` Steffen Prohaska
2007-10-21 23:49             ` david
2007-10-22  0:05               ` david
2007-10-22  5:38                 ` Steffen Prohaska
2007-10-22  5:01   ` Shawn O. Pearce
2007-10-22  5:45     ` Steffen Prohaska
2007-10-22 10:29       ` Johannes Schindelin
2007-10-22 13:04         ` Steffen Prohaska

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=1192956535617-git-send-email-prohaska@zib.de \
    --to=prohaska@zib.de \
    --cc=git@vger.kernel.org \
    /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.