On Wed, Jul 20, 2022 at 10:40 AM Alberto Planas
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.
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.
The dist-git / fedpkg idea was commented too. I personally do not like it. The point is a bit irrelevant, but as a developer, when I am using a model that is like the one in OBS (tarball, spec, changes and patches), I do not like the context switch that requires fedpkg to manage the tgz at a different level. In that regard "osc" is better, and with git-LFS there is a chance to replicate this experience using a mostly pure git model.
Git LFS is a bolt-on to Git, it just so happens that GitLab and GitHub know how to dereference it when the blobs are stored on *their* LFS servers. It is not hard to bolt on Dist-Git the same way. There's just been no drive to do that in Fedora because the "fedpkg" porcelain is more than sufficient. Git LFS does it with the .gitattributes file and storing extra goop in the git repository metadata, Dist-Git does it with the "sources" file. Six one way, half dozen the other. That said, if OBS has its own LFS server, then it really doesn't matter. Git repos in Pagure can be pointed to it like any other. Right now, Pagure has no specific plugin/integration for *any* blob storage system. The biggest annoyance I have with Git LFS from a general workflow perspective is that "git clone --mirror" produces unusable git repos with it, which makes downstream usage annoying. -- 真実はいつも一つ!/ Always, there's only one truth!