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.

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.

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's the same, except that I profusely disagree with the idea of being only "for untracked files". This is just as dangerous as not having it.

If it's only for untracked files, then you can't tell the difference between a file that's modified and a file-type that's misconfigured. So then you can only understand the LFS indicator by also looking at the tracking status column and reasoning that "if there's no indicator and no tracking status then it's misconfigured but if there's an indicator and no tracking status, then it's fine". Every single time, for hundreds of files, which is what game engine commits look like.

The LFS indicator has to be shown for all files that are handled by LFS, regardless of tracking status.

I don't know if you're LFS users. I used PlasticSCM until a month ago, and I promise you that not having this for LFS results big mistakes. This request completely overshadows any request an LFS user could otherwise have with SmartGit. I don't have a #2 feature request.

I'll take any minimum implementation. A column would be fine, then non-LFS users don't have to look at it. I only want to implore you to make it easy to distinguish between the states. Don't just have an LFS column with "Yes" or "No" in it, because it has to jump out at you. Have a column with either "LFS" or nothing, so that it's glaringly obvious if you've messed up the tracking status.

The reality is that LFS needs constant babysitting or you make wrong and permanent commits that cannot be recovered from without wiping your commit history and making a new repository. The time to catch this is before the commit, and without an indicator, it's impossible.

Actually, this is a deal-breaker. I'm currently subscribed to both SmartGit and GitKraken, but I realize that for my LFS projects, I'm forced to use GitKraken. So I'm going to have to suck it up and do GitKraken for the next year (will cancel SmartGit), and it's only over this feature.

Moving into LFS is relatively new to me, and accidentally not tracking giant files is a huge problem. I have 5 repositories that I'm seriously considering resetting all the history just to get huge files into LFS that were accidentally committed without updating .gitattributes.

So I have to use GitKraken. I'll continue to monitor this thread, and will come back to SmartGit the second it gets this feature, if it ever does. It's just too dangerous to not have it.

Here's an example of what GitKraken does, which provides the exact feedback you need to not accidentally do something stupid, expensive, and irreversible. For all of GitKraken's many flaws, this is one thing it does right.

By comparison, in SmartGit you're basically flying blind. You have no idea that you're about to make a huge mistake if this file-type isn't already tracked. All you can do is look at the Size column, and then double-triple-quadruple check .gitattributes that this file type is tracked. This is incredibly manual, and you still make mistakes all the time when you're doing this at scale. So there's really an opportunity for SmartGit to help here.