Hi Ben,
Le 11/04/2018 à 16:37, Ben Coman a écrit :
On 11 April 2018 at 05:05, Esteban Lorenzano <[email protected]
<mailto:[email protected]>> wrote:
Hi,
I’ve been wondering how to better fix the problem of having windows
and linux/macOS people contributing and the fact that files are
written in their native system format (crlf windows, lf for the rest
of the world).
I digged a bit and I found a couple a link that helped me (after
trying to understand the doc):
https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git
<https://stackoverflow.com/questions/170961/whats-the-best-crlf-carriage-return-line-feed-handling-strategy-with-git>
and it seems adding a .gitattributes file with this content:
# Auto detect text files and perform LF normalization
*text=auto
I see a few posts around that recommend reading
http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/
which about the above line says... "This is certainly better than
requiring everyone to be on the same global setting for core.autocrlf,
but it means that you really trust Git to do binary detection properly.
In my opinion it is better to explicitly specify your text files that
you want normalized."
and https://tinyurl.com/ya9xsprx says "We had a repo with * text=auto,
and Git guessed wrong for an image file that it was a text file, causing
it to corrupt it as it replaced CR + LF bytes with LF bytes in the
object database."
I'm unsure. Without it the system is subject to different users'
different global settings
and I'd guess that may be a more frequent problem than Git guessing
wrong. The latter
can be fixed by a user adding an extra .gitattributes entry explicitly
specifying the file was binary,
whereas the former seems to introduce a confounding factor.
So probably a good line to have.
*.sttext merge=union eol=lf
could fix the problem?
can someone confirm this?
"eol=lf" looks appropriate...
https://www.scivision.co/git-line-endings-windows-cygwin-wsl/
Most editors on Windows transparently handle LF line endings.
https://en.wikipedia.org/wiki/Comparison_of_text_editors#Newline_support
" merge=union" I am not familiar with, but I read at...
https://git-scm.com/docs/gitattributes
"union = Run 3-way file level merge for text files, but take lines from
both versions, instead of leaving conflict markers.
This tends to leave the added lines in the resulting file in random**
order and the user should verify the result.
Do not use this if you do not understand the implications."
What are the implications of lines being merged in a random order?
btw, has doing a callback from libgitto a custom merge driver in Pharo
been considered?
https://libgit2.github.com/libgit2/#HEAD/group/callback/git_merge_driver_apply_fn
There is a merge driver for parts of the filetree format implemented
with Pharo, it could be done on a more general basis if the Tonel format
exhibit more conflicts than usual.
But (and this is a big "but"), mixed Pharo / other things repositories
with very large files to merge could make things very hard on a
smalltalk-implemented merge algorithm.
In most (all?) my professionnal work, this is the case. I have among my
projects a mix FPGA design (verilog + vhdl) + C (drivers, runtime) +
Smalltalk, and the smalltalk part is small.
btw2, I found (https://githubengineering.com/move-fast/) interesting...
saying... "Despite being a C library, libgit2 contains many powerful
abstractions to accomplish complex tasks that Git simply cannot do. One
of these features are indexes that exist solely in memory and allow
work-tree related operations to be performed without an actual working
directory. [...] With the in-memory index, libgit2 is capable of
merging two trees in a repository without having to check out any of
their files on disk."
Yes, I considered that for GitFileTree. The current version uses
fast-import and archive (resp. to write and read) and in truth could
work on a bare repository, without working tree.
Oh, by the way: it also solves the #lf issue, because you do everything
the unix way, even on windows: GitFileTree now never touches a file of
the host system.
Thierry
On 11 April 2018 at 05:55, Esteban Lorenzano<[email protected]
<mailto:[email protected]>>wrote:
or a .iceberg file?
Esteban
ps: yep, we need it… we will have it, why not start now?
Do you mean Iceberg would clone a repo, and from its included .iceberg
file
a matching .gitattributes file would be created?
That seems like double handling.
Why not have the user edit the .gitattributes file directly from Iceberg?
Iceberg might provide some appropriate templates.
cheers -ben
