Re: possible gitattributes eol bug with new eol=crlf | lf support?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> wrote:
> 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
>
>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]