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