Files view (working tree only): add LFS icons or glyphs to GUI [SG-15043]

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.

Looking at this with the Log window.

Graph: Working Tree/Index is selected, unchanged OK, staged OK

Graph: any selected commit, no LFS icons.

Can you please provide some small test repository for which the problem is reproducible? Please send to smartgit@syntevo.com.

I still don't see this working. So this is the repository in SmartGit with one unchanged LFS file.

And here's the same in GitKraken:

I can't for the life of me figure out why SmartGit believes that there's now a badge. I've been through all menus many times, and I'm not seeing it.

To be completely honest, I ditched SmartGit for GitKraken, and it's only because of two minuses that I'm still seeing if SmartGit has become friendly to Git LFS, (1) GitKraken is not good for managing a lot of repositories (microservices) where SmartGit has a folder list, and (2) GitKraken's internal Git client requires dual authentication when using LFS.

I still don't understand why SmartGit seems on some religious mission to NOT have this feature. It's so simple, and it's an LFS dealbreaker. Once a large binary file makes it into the main repository, the whole thing is shot. You need to rebuild the repository from scratch and lose all history, and set up all users again. It's a catastrophic omission for SmartGit to refuse to inform people whether files will go into the main repo or LFS. For an LFS user, this is life or death, and SmartGit is categorically off the table for LFS without such a feature.

Per

I had not tested, nor highlighted those cases (working tree only, for log https://smartgit.userecho.com/en/communities/1/topics/1438-files-view-log-denote-lfs-files):

added: LFS icon

unchanged: LFS icon

modified: LFS icon

staged: LFS Icon

untracked : no LFS icon

This is the expected behavior in 22.1: there is currently no LFS icon yet for untracked files. For one of the next builds, we will add the "LFS" icon for untracked files, too.

With 22.1 build 19169 the LFS glyph should be present now for untracked files (information derived from "lfs" filters of your .gitattributes, as always).

I'm not clear on whether what you're showing is a future version or the current version running with different settings.

But it's also too subtle. Remember, this is an op-sec thing. You're not allowed to make one mistake ever with committing LFS files. Having been burned severely and repeatedly, I now have to choose a git client *entirely* based on whether it helps me not accidentally binary files to the regular repository. The SmartGit icons don't help, because they're basically pixel art. This will go wrong over and over and over.

The only thing that will work is a separate column with a big fat icon that says LFS, and GitKraken is one of the only clients that has this. The choice is made for me, I must use GitKraken regardless of what I think of it otherwise.

The question is whether you're trying to support the bare minimum or whether you're trying to be awesome at LFS. If you're trying to be awesome, and if you've used LFS for anything important ever, you'll know that there's a thermonuclear accident hiding in waiting on every commit, requiring a complete reformat of the repository if it happens. The only thing that stands in the way is the pixels showing that you're about to make a mistake. It looks like you're dedicating about 4x4 pixels to it. That's not enough.

I'll check back in a year and see if SmartGit's priorities has changed. The folder view is needed for microservices. This is a major flaw in GitKraken. But otherwise, GitKraken is the only game in town, because they're willing to tell you if you're about to trash your repository. On a game, LFS assets can sneak into every commit. SmartGit is way to quiet about it to be helpful.

It's too bad, it really is.

Please request another topic to optionally show an additional column for the LFS state.

Hi,

Good, I'll check it out.

Keep in mind that this icon is ONLY valuable for untracked files. Once a binary file has been commit to the main repository, the irreversible damage has been done. The only time this matters at all is for untracked files, and it should be as loud as possible. A little 5x5 pixel difference in the document icon doesn't solve the problem. This is about preventing the operator from casually making a catastrophic change to the repository that will require a total reformat and loss of all Git history.

Per

Please give SmartGit 22.1 preview #19170 a try. For the Log and Working Tree window there is a new LFS table column while the Standard window shows the LFS info at the right side of the Working tree's Files view.

Hi,

Where are these previews located? The last one I see is 22.1 Preview 13. from 7-28.

Per

I found it, I didn't realize it live-updated.

But it doesn't seem to work yet. Here is a PNG file, which is in .gitattributes:

And in GitKraken:

Thinking it had to do with a repository not being initialized, I installed LFS on a less important project, and I also couldn't trigger anything in that column.

Did you already set the low-level property pull.queryRemoteLfsLocks to true and pulled?

I wasn't aware of that setting, where do you set it?

But just to make sure that isn't a huge misunderstand, is the LFS stuff you're working on about locks? If so, I've failed to explain that this is purely about being aware of which things will go into LFS and which will go into the repository before the commit. I've never used an LFS lock.

It is about both LFS attributes. Please see the screenshots:

The LFS column is definitely empty for me in any view on files that GitKraken is definitely picking up as LFS files, and I'm definitely on 19170.

Is the repository public, so we can give it a try ourselves? If not, can you please compose a small test repository for which the problem reproduces and send us to smartgit@syntevo.com?