Files view: add LFS icons or glyphs to GUI [SG-15043]

strott 3 years ago updated by Marc Strapetz 1 week ago 13

Please consider adding an icon or a glyph to display the LFS tracking state of each file/file type. GitKraken, Bitbucket and Gitlab all have a little tag that says LFS next to files being tracked as LFS, it would be nice if Smartgit had the same.

Not sure I'd want an icon (maybe an extra column though?), but at least a notification in the changes tab when the file is selected.

I'll repost a request I made in the forum: https://groups.google.com/forum/#!topic/smartgit/PMh7CrwLAMM


I was toying with LFS locally so I needed a local server (can't serve LFS files from a directory), so I used gitea and noticed it very explicitly says when a file is LFS-tracked, like in this commit which changed both a large and a regular file:

... I would love to have this in Smartgit! maybe in the review tab header, where it sometimes shows extra info such as "line endings LF vs CRLF".

In some context (file history, I think), gitea also actually follows the large file and displays its content!

... which admittedly has limited interest for large binaries, but was nice in my case because my .large test file is actually text. Still a nice option IMO, to more closely mimic what happens for non-LFS files.

I created a separate thread, not knowing this one was here. Some points from the other thread:

* Not having an LFS indicator quickly results in wrong and permanent commits of huge files that should have gone into LFS. The only opportunity to realize that your LFS status is wrong is before the commit.

* It should not only be for untracked files, it should be for all files, regardless of tracking status. Otherwise you can't tell the difference between a file that's modified and a file-type that's misconfigured, requiring you to always have to understand the LFS indicator relative to the tracking status, over and over for thousands of game-content files. Your brain will crap out, and you'll inadvertently put some new file type into the permanent non-LFS repository.

* The LFS indicator should be easily readable, so it's glaringly obvious whether a file is handled by LFS. If it just shows two text statuses, i.e. "Yes" and "No", then it doesn't jump out at you that you're about to make a big and permanent mistake.

* For an LFS user, this is basically a dealbreaker. I'm forced to do all my LFS repositories through GitKraken over this single issue, because it's not safe to use SmartGit. I already have 5 repositories with huge, permanent non-LFS files. Every time a 3rd party plugin is added to the project, it brings some new, exotic, large file-type that inadvertently gets into the non-LFS repository. I'm seriously considering abandoning a year of commit history on one repository just to get these files out.

* Don't judge importance by the number of upvotes. A non-LFS user couldn't care less about this. For an LFS user, the lack of this feature results in immediate harm to repositories, by inadvertently uploading large files that will never leave.

It would be great to hear from Syntevo whether they ever intend to add this feature. I can see it has been requested for the last 5 years, which makes me really nervous. Not having this is a dealbreaker for using LFS with SmartGit, not just as some emotional rant, but that it's really 100% unsafe to use SmartGit on a large project.

But if they've turned down this request over and over for the last 5 years, it sounds like they have some antagonistic opinion towards it.

So it would be really super awesome to hear what SmartGit even thinks of this indicator. I'm a big boy, and if you really are against it, just let me know, and we can plan accordingly.

Without this indicator, we're absolutely *forced* to not use SmartGit for a large project. Otherwise, it's gigabytes of spam in the regular repository, all committed by accident. SmartGit is a non-starter for e.g. a game project without this. And it would take Syntevo a few hours to add, which makes it all the more puzzling that they're so apparently against it.

As of now only 6 of ~x0.000 users voted for this feature, so it doesn't look really important to us.

But this is super flawed reasoning. This feature only matters if you use LFS, so this features scores 100% among your LFS users, and 0% for your non-LFS users.

It's so critical that now I know where you stand, I have to leave SmartGit. This is not just some door-slamming rant, it's really true, that I'm 100% unable to use SmartGit for a large project. It's an irresponsible implementation.

The question is, why do you support LFS at all, when apparently 0.0000% of your users care about it?

In our products, I would NEVER give the finger to a feature that's 100% important to a subset of the users. I think this is really bad on your part.

Well, at least, thanks for being honest about this. I have no choice by to cancel SmartGit. I really don't want to, this is with a gun to my head.

And it's now canceled. It was subscription 249691774. What an ultra-bummer.

I agree, it is baffling why this is a tough request. Add another column type and the word LFS if its being tracked as LFS. Or a asterisk, or anything really.

I agree with Holmes. Smartgit ends up being extremely challenging to use with projects that have large blobs. The repo databases become extremely slow if a giant binary file is committed on accident.

Will an indicator in the icon, including some more details in the tooltip be sufficient?

Yes an icon and maybe a tool tip like "handled as LFS object" or just "LFS object" would be sufficient to help us all a lot.

In a later stage, it might be nice to have hints either at the file or in the .gitattributes file, if a file should be handled via LFS based on the patterns in .gitattributes, but it isn't yet. (I'm not sure if this is an easy task to achieve.) - But this is a different proposal :).

Indicating what files are normal and what are LFS files would be a great help!


Maybe, if an LFS placeholder file was checked out but not replaced. Some kind of LFS error symbol like a Merge Conflict


Please give 22.1 build 19042 a try which should now indicate Git-LFS states: "handled", "lockable", "locked by yourself", "locked by <...>" and "should be handled" (but is actually a plain blob).

Was this feature dropped? Testing 22.1 Preview 9 (build 19130), and I'm not seeing any indicators anywhere.

It's working fine for me. Is Git-LFS properly configured? Can you please provide some small test repository for which the problem is reproducible? Please send to smartgit@syntevo.com.