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
<eric.gwin@xxxxxxxxxx>
To:
Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>,
Date:
01/18/2013 07:09 PM
Subject:
Re:
[cross-project-issues-dev]
Corrupt Simrel repo???
Sent by:
cross-project-issues-dev-bounces@xxxxxxxxxxx
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 <ed@xxxxxxxxxxxxx>
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<eric.gwin@xxxxxxxxxx> 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
>>> cross-project-issues-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>>
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>>
>> _______________________________________________
>> cross-project-issues-dev mailing list
>> cross-project-issues-dev@xxxxxxxxxxx
>> 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
> cross-project-issues-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
|
