On Sun, May 31, 2020 at 03:30:39PM +0200, Sebastien Marie wrote:
> On Sun, May 31, 2020 at 02:46:59PM +0200, Stefan Sperling wrote:
> > > 
> > > First, a general remark about "if a symbolic link cannot be installed we instead
> > > create a regular file".
> > > 
> > > I am a bit unsure about this semantic. Does this particular file is managed in a
> > > special way ? or does the next got command will just assume a symlink was
> > > deleted and replaced by a plain file ?
> > 
> > We can never trust the on-disk state anyway. Even if we installed a symlink
> > the user can replace that link with a regular file, a directory, a fifo, etc.
> > 
> > [...]
> > 
> > Then we can look at what's on disk. It might be a real symlink, or something
> > else. Each operation can now do something that fits the semantics we want.
> >  
> > Is it enough if we simply render symlinks harmless upon checkout?
> 
> My point was I find odd that after a "got checkout" a "got diff" would already
> points that things changed.

Yes, that would be odd. I don't plan to implement it like that.

Note that in got 0.36 all symlinks end up as regular files on disk which
contain the target path because the current implementation simply reads
blob contents and writes them into a regular file:

$ git remote -v
origin  https://github.com/openwrt/mt76.git (fetch)
origin  https://github.com/openwrt/mt76.git (push)
$ ls -l firmware/
total 400
-rw-r--r--  1 stsp  users  -  2.1K Jan  4  2016 LICENSE
lrwxr-xr-x  1 stsp  users  -   27B Jan  4  2016 mt7662.bin@ -> mt7662_firmware_e3_v1.9.bin
-rwxr-xr-x  1 stsp  users  - 77.1K Jan  4  2016 mt7662_firmware_e3_v1.7.bin*
-rwxr-xr-x  1 stsp  users  - 80.0K Jan  4  2016 mt7662_firmware_e3_v1.9.bin*
-rwxr-xr-x  1 stsp  users  - 25.7K Jan  4  2016 mt7662_patch_e3_hdr_v0.0.2_P69.bin*
lrwxr-xr-x  1 stsp  users  -   34B Jan  4  2016 mt7662_rom_patch.bin@ -> mt7662_patch_e3_hdr_v0.0.2_P69.bin
$ got co -p firmware . /tmp/mt76-firmware
A  /tmp/mt76-firmware/LICENSE
A  /tmp/mt76-firmware/mt7662.bin
A  /tmp/mt76-firmware/mt7662_firmware_e3_v1.7.bin
A  /tmp/mt76-firmware/mt7662_firmware_e3_v1.9.bin
A  /tmp/mt76-firmware/mt7662_patch_e3_hdr_v0.0.2_P69.bin
A  /tmp/mt76-firmware/mt7662_rom_patch.bin
Now shut up and hack
$ ls -l /tmp/mt76-firmware/mt7662.bin
-rw-r--r--  1 stsp  wheel  -   27B Jun  1 10:06 /tmp/mt76-firmware/mt7662.bin
$ cat /tmp/mt76-firmware/mt7662.bin
mt7662_firmware_e3_v1.9.bin$

So this behaviour is our starting point.

Note that this behaviour matches how Subversion installs symlinks on
OS platforms which don't support symlinks (i.e. Windows).

> I agree that such harmfull symlink shouldn't be created. I am just uncertain if
> the behaviour should be:
> 
> 1- create a regular file (instead of a symlink)

I think it should create a regular file.

Symlinks may have two possible on-disk representations:
An actual symlink if the target is safe, and a regular file otherwise.
This just affects the on-disk state. Meta data looks the same, and all
commands will behave exactly the same way for both on-disk representations.

Any software that cares about there being an actual symlink on disk is
software which uses files in the work tree: editors, compilers, or build
systems. Got itself doesn't need to care.

By installing a regular file we can allow users to edit such links.

Users might expect a symlink and find that a regular file has been installed.
This will be the documented behaviour in case a symlink target path points
outside of a work tree (and also applies if a symlink points outside of a
work-tree's path-prefix).

Uses can edit this file to change the target path. Only now will 'got status'
and 'got diff' display it as modified. If the change is committed, the file
will become an actual symlink if the new target path is safe to use.

Given an actual symlink, changing the link target with ln -s would have the
same effect. And if the new target points outside of the work tree, the link
will now be installed on-disk as a regular file.

Users will need a way to see whether a regular file is in fact a symlink.
'got tree' identifies files which are stored as symlinks in the repository,
so that's one way of finding out. We could also add 'got info' or a similar
command which displays meta-data for any path in a work tree, including the
file type (regular or symlink).