[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [qvtd-dev] Line Endings was: Branch merging
|
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
