Hi
The Simrel project explicitly specifies Unix line endings, which I
find to be an almost mandatory practice with GIT so that's good.
autocrlf IMHO is the wrong solution to the wrong problem; if we all
have the identical file we won't need fragile adaptation. A CM that
modifies files is an obviously bad idea. CVS had its problems here
too; often there were spurious 100% changes in the CVS difference
view.
Because not all tooling respects the line ending setting, I work
with whitespace showing so that I can detect where broken line
endings are coming from. Hence https://bugs.eclipse.org/bugs/show_bug.cgi?id=388418
and some others.
I strongly recommend that new GIT users watch their whitespace
stability very carefully. Convert all rogue files to Unix line
endings before commit, but don't use the Convert Line Endings
command if you use also have advanced XML tooling such as Papyrus or
WTP installed; a) because you need to be prepared to have a coffee
break; and b) because converted files may be reformatted provoking
further changes.
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=390792).
Regards
Ed Willink
On 19/01/2013 06:54, Ed Merks wrote:
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
_______________________________________________
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/6041 - Release Date:
01/18/13
|