After thinking about the "line ending" issue some, I think autocrlf="false" is still the best "default advice" ... unless someone knows of a reason that doesn't work for them. The way I've tried to address this is to update the wiki, by adding a "note" section (pasted below). If someone can write this section better or explain it better, or knows how to mark up the wiki better so it is a "side note", then please do. No review needed.
= = = = = Make sure that core.autocrlf = false and on Windows core.filemode = false. [Note: some people have found if they use other tools in addition to Eclipse, that core.autocrlf = false does not work well for them. The most important thing to avoid is files with "mixed line delimiters" since "autocrlf" will never be able to "fix up" files like that. You may want to turn on the Eclipse preference for "visible white space" so you can see if you or your tools introduce mixed line delimiters and if so correct them with "File, Convert Line Delimiters To ..." (after setting content type, described below) or use command line tools such as dos2unix to fix them to have consistent delimiters.] From: Ed Willink <[email protected]> To: Cross project issues <[email protected]>, Date: 01/19/2013 03:31 AM Subject: Re: [cross-project-issues-dev] Corrupt Simrel repo??? Sent by: [email protected] 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 <[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 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 _______________________________________________ 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
