Add support for Git LFS
Git LFS seems to be used frequently enough that it may be worth adding support for it. I don't think it'll be a priority for me very soon, but I guess that depends on how many people want it. [The specification](https://github.com/git-lfs/git-lfs/blob/main/docs/spec.md) says that it uses clean/smudge filters. We don't have anything like that yet. So the first step is probably to add support for that. We could make the filters only available internally (i.e. in Rust code) to start with to keep it simple. On the other hand, it might not be hard to make them user-configurable. Another option is to add a separate file type in the data model for LFS entries. For reference, we currently have [files, symlinks, trees, conflicts, and gitmodules](https://github.com/martinvonz/jj/blob/f9298582a78a4d06e6b9c5b51c67e034e7406739/lib/src/backend.rs#L291). I haven't thought through the consequences yet. There should be no difference to the user and no difference in the representation when using the Git backend. However, clean/smudge filters are probably useful to have anyway. Oh, one *possible* advantage of representing LFS entries in the model is that we can decide to always leave merged LFS files as conflicts, without downloading the files until the user checks them out or looks at the diff etc. I don't yet know what other aspects of Git LFS we need to consider. Originally requested in #77.
Posted by martinvonz on Feb 24, 2022, 6:04 AM
Tags
Related issues
- This is the biggest problem with contracts, there's simply no way to actually say "please always execute this check".
- I don't disagree with you on this, I worked my whole life in corporate and haven't worked as a OSS maintainer before, though I will _and ...
- the new VSCode UI, looks cute, i don't like it.
- I've been working on my own private harness for the past 8 months, and I've been collecting ideas from such repos I've stumbled upon.
- The way AI is able to interact with outside resources is pretty impressive, but the quality of code it produces to me is still questionab...
- Add PR-style review comments in Git Diff UI that feed into the active agent thread
Raise real-world problems, find people facing the same issue, and discuss solutions.2,500 issues0 comments
ux (Software)
This is the biggest problem with contracts, there's simply no way to actually say "please always execute this check".
I don't disagree with you on this, I worked my whole life in corporate and haven't worked as a OSS maintainer before, though I will _and ...
the new VSCode UI, looks cute, i don't like it.
I've been working on my own private harness for the past 8 months, and I've been collecting ideas from such repos I've stumbled upon.
The way AI is able to interact with outside resources is pretty impressive, but the quality of code it produces to me is still questionab...
Add PR-style review comments in Git Diff UI that feed into the active agent thread
Thanks for indulging me so far, by the way, I really appreciate this discussion, it's very stimulating.
Migrate GDScript to the GDExtension mechanism and overhaul the implementation
Add support for Git LFS
Git LFS seems to be used frequently enough that it may be worth adding support for it. I don't think it'll be a priority for me very soon, but I guess that depends on how many people want it. [The specification](https://github.com/git-lfs/git-lfs/blob/main/docs/spec.md) says that it uses clean/smudge filters. We don't have anything like that yet. So the first step is probably to add support for that. We could make the filters only available internally (i.e. in Rust code) to start with to keep it simple. On the other hand, it might not be hard to make them user-configurable. Another option is to add a separate file type in the data model for LFS entries. For reference, we currently have [files, symlinks, trees, conflicts, and gitmodules](https://github.com/martinvonz/jj/blob/f9298582a78a4d06e6b9c5b51c67e034e7406739/lib/src/backend.rs#L291). I haven't thought through the consequences yet. There should be no difference to the user and no difference in the representation when using the Git backend. However, clean/smudge filters are probably useful to have anyway. Oh, one *possible* advantage of representing LFS entries in the model is that we can decide to always leave merged LFS files as conflicts, without downloading the files until the user checks them out or looks at the diff etc. I don't yet know what other aspects of Git LFS we need to consider. Originally requested in #77.
Comments (0)
No comments yet. Start the discussion.