On Tue, 1 Jun 2010, Junio C Hamano wrote:
"Henrik Grubbström (Grubba)" <grubba@xxxxxxxxxx> writes:
This is useful for repositorys not containing fully normalized files
(eg containing CRLF's or expanded $Id$ strings), where a later attribute
change implies a conversion mode change. Without this set of patches
the user would need to recommit semantically unchanged files to get
a clean index.
A more fundamental (or perhaps "silly") question is if that "user would
need to" is necessarily a bad thing. If the user wants to cleanse such
abnormality in the recorded blobs, shouldn't there be a conscious act,
iow, a commit that records that "I am fixing that mistake, and from now
on, the recorded data are normalized"?
I believe that users typically aren't interested in if data in the
repository is on normalized form or not (witness the autocrlf=true
discussion a few weeks ago, where one of the main complaints was
that it required a renormalization (which fg/autocrlf attempts to
solve for that specific case by not normalizing)), as long as they
get the expected content on checkout.
This set of patches allows for an incremental, on-demand normalization.
Eg the user could switch the attributes for a group of files from
*.bat -crlf
(let's assume *.bat files use crlf linebreaks) to
*.bat -crlf text eol=crlf
and then have git normalize the individual files when there's actually a
semantic reason for a change. With the current eb/core-eol patches this
change would cause a dirty index on checkout. The user who committed the
change however has a clean index until any of the files affected is
touched.
In my case, I have repositories containing files both requiring crlf and
lf line endings, and additionally have expanded $Id$-strings that I want
changed on first semantic change (but not before). To be able to use a
git binary without this patchset I'd have to do a
git commit -a -m 'Normalized'
as the first thing after a checkout.
I could of course add a config option to control the behaviour (hmm, or
maybe an attribute?).
Perhaps I am missing something very trivial that you have already
explained to the list but I forgot amid my moving and other confusion, and
if that is the case I apologize in advance ;-).
No problem.
--
Henrik Grubbström grubba@xxxxxxxxxx
Roxen Internet Software AB grubba@xxxxxxxxx