On Mittwoch, 20. Juli 2022, 16:39:55 CEST Alberto Planas wrote:
On Wednesday, July 20, 2022 4:02:12 PM CEST Neal Gompa wrote:
GitHub's implementation has issues where smudging can be broken when doing complex merges that have LFS objects touched.
I do not think that LFS is set into stone yet, and this kind of interaction should be tested.
yes, definitivly. It was mainly used to represent the file blobs from OBS source server commits. We wanted to avoid to duplicate all these files and therefore created a _read-only_ LFS bridge to OBS source server. This means also that * the .lfsconfig will also work when you move a git repository to another git hoster, as the URL to the LFS storage is hardcoded * the .lfsconfig needs to be removed/adapted when replacing the assets. IMHO using the pbuild/OBS remote assets would be a good way to go here, but it does not mean that this is the only allowed way. Using the remote assets we would avoid the mentioned problems when pushing the git repo to another host and we also would keep tracking data from where the resources came (something what is not working with LFS out of the box). It would also help us to create proper provenance files for reproducibility. Something what can only increase the trust in our code base ...
IMHO one of the advantage of LFS is that is a very simple protocol, that can behave very nice with OBS. For example, there is currently in the PoC a proxy in place that routes back to OBS for old tgz, avoiding duplication. Future commits can delegate into OBS or another LFS server from this point, without much notice from the users PoV.
Right, you can find an example package here btw:
https://gitea.opensuse.org/adrianSuSE/git-example-lfs
The .lfsconfig is pointing to a (non final) OBS LFS provider.
But again, this is only intended for past commits, not for future ones
when git will be the master source.
--
Adrian Schroeter