Re: [PATCH v4 0/5] Patches to avoid reporting conversion changes.

From: Henrik Grubbström <grubba@roxen.com>
Date: Jun 3, 2010, 16:00 UTC
Message-ID: <Pine.GSO.4.63.1006031543340.22466@shipon.roxen.com>
In-Reply-To: <7vfx16oxmz.fsf@alter.siamese.dyndns.org>

On Tue, 1 Jun 2010, Junio C Hamano wrote:

Show 13 quoted lines

> "Henrik Grubbström (Grubba)" <grubba@grubba.org> 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@grubba.org Roxen Internet Software AB grubba@roxen.com