On 12 April 2018 at 01:47, Thierry Goubier <thierry.goub...@gmail.com>
wrote:

> Hi Ben,
>
> Le 11/04/2018 à 16:37, Ben Coman a écrit :
>
>>
>>
>> On 11 April 2018 at 05:05, Esteban Lorenzano <esteba...@gmail.com
>> <mailto:esteba...@gmail.com>> 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.
>

I was thinking that a smalltalk-implemented merge algorithm would only be
used for the Smalltal/Tonel code,
not for any other files.  And maybe, when a merge is invoked from Iceberg,
the callback to the merge-driver
might present conflicts in a GUI to be resolved, but I guess such would
require a threaded-VM.

cheers -ben



> In most (all?) my professional 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<esteba...@gmail.com <mailto:
>> esteba...@gmail.com>>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
>>
>>
>
>

Reply via email to