Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [qvtd-dev] Line Endings was: Branch merging

Hi

Checking on the autocrlf option, most of whose documentation just says it makes it work 'right'.

autocrlf=true is what I particularly dislike.

I have no objection to autoconversion from Windows to Unix on input, but it also does autoconversion in the reverse direction maximizing the number of erroneous files in existence.

autocrlf=input looks much more promising

It only converts Windows to Unix, no reverse conversion. But does it work? Does EGIT staging detect that no commit is needed for both Windows and Unix line endings? Does Platform compare successfully show no change? Does EMF Compare work sensibly? I doubt it. Why would platform compare / EMF compare look at a repo-specific GIT option?

How do you guarantee that all users always have consistent non-standard EGIT settings?

I generally check files before committing, since I know that

EMF genmodel needs import repair, @Override repair
Xtext generate needs import repair, @Override repair, line endings repair
....

Until repaired, commit lists are ridiculously large.

    Regards

        Ed

On 20/02/2015 00:25, Adolfo Sánchez-Barbudo Herrera wrote:
Hi Ed,

I think you are missing the point of the current need of being careful to not commit windows line endings, which can be/are currently produced in windows environments by tools such as the widespread EMF. It´s very easy to forget to pass that specific option when saving.

I think I don´t have anything else to contribute to this discussion. Let it be as it is.  At least now a "better" saving is done in the cs2as.tests test cases.

Regards,
Adolfo.


On Thu, Feb 19, 2015 at 7:15 PM, Ed Willink <ed@xxxxxxxxxxxxx> wrote:
Hi

I recall one positive recommendation on autocrclf to set it one way. A few months later I remember another positive recommendation to set it the other way. There is no consensus. Magic.

Amongst the unsupported options are Buckminster's, see the "is git.auto.fetch implemented at all?" newsgroup thread that I have pinged twce without response since 5-October; another reason from moving from Buckminster; support has terminated.

The only Windows tool I use that has problems with Unix line endings is Notepad, so I use Notepad2.

Again IMHO, a tool that does not support Unix line endings is deeply suspect.

    Ed



On 19/02/2015 18:04, Adolfo Sanchez-Barbudo Herrera wrote:
Hi Ed,

I'm not sure which option you mean, or which are your evidences...

I'm referring to the autocrlf repository configuration property, which EGit is currently happily handling. I normally work showing white-space characters and I was seeing windows line endings in my working repository because I had that autocrlf option to true. Perhaps, you should probably be seeing Unix line endings (if you didn't have such an option). The only problem when working with windows line endings is that if some local tooling generates Unix line endings, EGit will show some changes. When those are committed no real change will take place (as long as the git repository files contains Unix line endings).

[Note that In Windows, an EMF Resource.save with no options, it was giving me models with windows line-endings. Hence, the need to pass options to the MtcBroker and PivotModel to always produce w]

I'm not claiming I/anybody need multiple line endings. Just one, but any user might want to work with Windows line-endings and our tooling currently needs to produce Unix line-endings to conform to their project specific properties.

What I'm saying is that, and providing that GIT gives you automatic Windows2Unix conversion when comitting files, since I'm working on a Windows environment I should be happy of having windows line ending content in my working repository. One reason: many other windows tools might only deal with windows line endings files.

The same might occur when then user is a Unix/Mac one. It should convert to the default/standard line ending for the corresponding OS.

Regards,
Adolfo.
On 19/02/2015 17:31, Ed Willink wrote:
Hi

EGIT/JGIT does not even implement the required option so attempting to
use it is pointless.
>

IMHO, a CM tool has no right to attempt to change files at all.

IMHO again, anyone who wants multiple line endings deserves to be shot.
Fortunately Unix works everywhere. Unfortunately not all tools yet
respect project preferences (OCL tooling is not guiltless either.).

You may recall from CVS days that sometimes CVS compare reported a 100%
diff too and IIRC one half of the 100% was shown as blank, so not even
CVS got it right.

With a Unix files only policy all bugs are attributable to us (assisted
by inferior tooling); GIT is never at fault.

     Regards

         Ed

On 19/02/2015 16:52, Adolfo Sanchez-Barbudo Herrera wrote:
On 18/02/2015 18:10, Horacio Hoyos Rodriguez wrote:
Please ensure that all projects have explicit Unix, UTF-8
characteristics. Please ensure that all non-binary files are converted
to Unix/UTF-8 before committing. Unfortunately some model tools do not
get this right. If Windows files are accidentally committed, please
rework the offending commits.
Hi Ed,

This line ending is controversial. I remember we had tough discussions
years ago. I recall the conclusion was:
a) No use Windows2Unix git conversion in our local repositories (which
I was using since I forgot to change)
b) Let's use project specific settings and work always with Unix line
endings.

>From my point of view, the best option to avoid introducing windows
line endings is using the Windows2Unix git conversion. I don't
remember what was wrong with that and why we needed a) + b), but that
could easily have been EGit deficiencies from the early tool quality.

The only theorical problem I see by setting that Windows2Unix
conversion is that whenever we generate something in local which
produces Unix line endings we will get undesired changes. For example,
I've spotted Resource.save options in which the Unix line-ending is used.

This is probably useful for our projects which try to work with Unix
line-endings but that could be dreadful for others which expect to
work with windows line endings.

- Forcing Linux line-endings in our tooling is bad.
- Trying to inspect corresponding project settings would be ideal, but
probably difficult to handle since we normally work with URIs rather
that the Eclipse IResource APIs.

I have the impression that if we deal with default XMIResource
serialize options (i.e. no options), everything should just work as
long as :
c) We use the default Windows2Unix conversion when committing stuff to
git (providing this is properly working)
d) No specific project settings would then needed, they should happily
work with OS defaults. So, a new file can be created with windows
line-endings because they will be comitted to the git repo with the
Unix one.

That said, and assuming that you might not like changing/adopting
that. I've created some changes[1] so Mtc broker accepts some saving
options, giving the client (in this case, my test cases) a chance to
save as they prefer. In this way, I've set a couple of options so they
are always serialised with UTF-8 enconding and Unix line endings.

[Update: The util is in the test cases infrastructure so they can be
reused, and I've used the TestXMLUtil as you seem to prefer]

Regards,
Adolfo.

[1] Now: commit d53777b0c69e15dc20af7fa592e1e52fc461e1fc
_______________________________________________
qvtd-dev mailing list
qvtd-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvtd-dev


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5646 / Virus Database: 4284/9143 - Release Date: 02/19/15



_______________________________________________
qvtd-dev mailing list
qvtd-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvtd-dev
_______________________________________________
qvtd-dev mailing list
qvtd-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvtd-dev


-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5646 / Virus Database: 4284/9143 - Release Date: 02/19/15



_______________________________________________
qvtd-dev mailing list
qvtd-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvtd-dev



_______________________________________________
qvtd-dev mailing list
qvtd-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvtd-dev


No virus found in this message.
Checked by AVG - www.avg.com
Version: 2015.0.5646 / Virus Database: 4284/9146 - Release Date: 02/19/15



Back to the top