Re: possible gitattributes eol bug with new eol=crlf | lf support?
- From
Robert Buck <buck.robert.j@gmail.com>
- Date
- Sep 12, 2010, 19:58 UTC
- Message-ID
- <AANLkTi=9Wv9_s2zDEdpc8Dn7qXSRepZSToKkOrAoTQnR@mail.gmail.com>
- In-Reply-To
- <4F27AD7B-2B2D-4378-B1D5-6F380396E0FF@gmail.com>
Thanks Eyvind,
I tried it on an experimental repository and it worked. Thank you for your recommendation.
I also found the following link at github which achieves a similar effect. Adding this for the record in case someone else searching for a solution in the future wanted more detail.
http://help.github.com/dealing-with-lineendings/
The one thing I find curious about the github article is that it seems to recommend using autocrlf=true for ALL platforms once the linefeeds have been normalized.
Let me ask for an opinion about this... Given we have an environment of mixed Windows, Mac, and Linux developers, that we have just migrated from svn and over 2000 files in the repository have messed up line-endings, what would be your recommendation for autocrlf settings? Oh, important note, because neither cygwin nor msysgit support newer versions of git, we do not have the flexibility of running your new "eol" support on Windows, while Linux developers do.
So if we did this one-time normalization on all repositories, all branches, what holistic approach (eol, autocrlf) would keep our files sane for a mix of 1.7.2 and later, and 1.7.0.1 and earlier, Windows, Mac, and Linux?
Thanks Eyvind.
-Bob
On Sun, Sep 12, 2010 at 7:46 AM, Eyvind Bernhardsen <eyvind.bernhardsen@gmail.com> wrote:
Show 15 quoted lines
> On 10. sep. 2010, at 23.27, Robert Buck wrote:
>
>> I don't understand the inner workings of .git/index, but is removing
>> that file destructive to history or anything? What are the
>> implications of that delete-command?
>
> Removing the index will lose the changes you've staged ("git add"ed) for the next commit, but your working directory won't be touched. If you've added a file and then modified or deleted it, you would lose the version of that file that was in the index.
>
> "git reset" then rebuilds the index identically to the HEAD commit, but without the staged changes and (importantly) the stat cache. The point is to make git re-check every file to see if it has been modified.
>
> Sorry, I should have mentioned the downsides.
>
> - Eyvind
>
>