David,
I'm not sure it's good advice to suggest autocrlf=false. The problem
is, if the wrong endings are contributed by some tool, they'll end up
pushed to the actual repo in that incorrect form (the repo itself must
use \n) and then when anyone pulls, they'll end up with those wrong
endings. I had to repair the whole EMF and XSD repos because of this
problem so if you see wrong line endings in the repo, you need to take
action to fix all those files.
Note that EMF itself was one of the things that contributed to this
problem, i.e., XML serialization always uses the Java system default for
line endings, or at least it did until
https://bugs.eclipse.org/bugs/show_bug.cgi?id=388418 was recently
fixed. That bugzilla introduces a new option to respect the line
endings in the resource or the workspace preference in effect for that
resource, if it doesn't exist yet. With the latest EMF version, the
generator automatically uses the new option in the generated editor.
The b3 aggregator likely needs to be regenerated to avoid having folks
on Windows corrupting the repo to which they push the their aggregated
results.
Also note that EGit does a much better job respecting autocrlf=true
these days, so perhaps advice based on its previously broken behavior
should be reconsidered.
Regards,
Ed
On 19/01/2013 3:16 AM, David M Williams wrote:
Do people who always have to "deal with the consequences" use Windows?
Linux? Mac?
Do they use EGit or command line?
I ask, since I do not see the problem you describe, using Linux and EGit.
But, I did look closely at the file, and see that it had mixed line
endings (some "windows" CRLF and some "linux" LF).
This, in turn, makes me wonder if participants have read
http://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build#Configuring_the_repo
and
http://wiki.eclipse.org/Simrel/Contributing_to_Simrel_Aggregation_Build#Configuring_the_workspace_content_types
In short, use autocrlf=false and define your content types and/or
associate the file types with text editors.
autocrlf=false should prevent a "change" from occurring on checkout,
and having correct content types defined make it easy to fix using
"Convert Line Delimiters To ... ". If you're the CLI only type, you'd
have to use "dos2unix" to fix.
I have corrected the delimiters (so it is now no longer a "test case")
... but, having the repo configured correctly will help avoid it in
future and make it possible for you, participants, to fix files in the
future, if it happens again.
Maybe we should add a reminder "test case" file, with deliberate mixed
line endings that'd say "if you see this file as changed, you need to
set autocrlf=false"? :) At least, I'm assuming that was (one of) the
problems ... like I said, I've not actually seen the issue.
HTH
From: Eric Gwin <[email protected]>
To: Cross project issues <[email protected]>,
Date: 01/18/2013 07:09 PM
Subject: Re: [cross-project-issues-dev] Corrupt Simrel repo???
Sent by: [email protected]
------------------------------------------------------------------------
Hi,
I understand that the message is usually a standard Git protection to
keep me from inadvertently overwriting edited files. However, my point
is I haven't edited the file. Ever. It "comes" edited when the repo is
cloned. Therefore, I surmise that the file is, in fact, corrupt in the
repo, and everyone using that repo is having to deal with the
consequences.
It would be nice if it were fixed.
Eric
On 2013-01-18, at 4:54 PM, Ed Willink <[email protected]> wrote:
> Hi
>
> This is standard GIT protection for edited files.
>
> As the message says you must either preserve of lose the changed files.
>
> To lose it/them just replace all files shown in the Staging View by
HEAD. Then you're good to go.
>
> Regards
>
> Ed Willink
>
> On 18/01/2013 21:45, Benjamin Cabé wrote:
>> FWIW I have the very same issue, so sth is probably wrong in the
git repo itself indeed...
>>
>> Benjamin
>>
>> Eric Gwin<[email protected]> a écrit :
>>
>>
>> Ok. got past it again by "unstaging" the file. and was able to
checkout the Juno branch, but it should still probably be looked into.
>>
>> -Eric
>>
>> On 18/01/2013 2:14 PM, Eric Gwin wrote:
>>> David,
>>>
>>> For a while now I've been having trouble switching my simrel
branch. I thought it was just my system, but tried from another system
recently. Any attempt to switch to the Juno_maintenance branch is
giving me:
>>>
>>> "error: Your local changes to the following files would be
overwritten by checkout:
>>> soa-bpel.b3aggrcon
>>> Please commit your changes or stash them before you can switch
branches."
>>>
>>> This is from a freshly cloned repo.
>>>
>>> I don't know if the issue is mine (can't see how), or a corrupt
git repo, or something to do with the soa-bpel file.
>>>
>>> -Eric
>>>
>>> _______________________________________________
>>> cross-project-issues-dev mailing list
>>> [email protected]
>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> [email protected]
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> [email protected]
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2013.0.2890 / Virus Database: 2639/6039 - Release Date:
01/17/13
>>
>>
>>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
