Your comments

Just mark the repositories as favorites and SmartGit will fetch every 10 minutes in the background for you. Then it shows red and green arrows if you're ahead or behind the remote repo.

This would be a huge improvement. We also have lots of submodules and need to diffs on them from time to time.

I would have a similar problem / use-case.

If a branch with a stash on top was rebase-merged in GitHub, I would like to remove my local branch, because work is done, but my stash is keeping this side "branch" alive. Similar it happens, if I locally rebase a branch, then my stash is left behind somewhere deep down in history.

A "rebase" for stashes would allow to drag stashes up in history and also to keep them up-to-date / less conflicting with the current development.

(Converting stashes into real, but local branches sound to much work for a lightweight stash.)

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

I also encountered this use case here and there. I would help a lot to know where the problem is located.

Bugged described the use case for a very wide submodule structure. In my use case it's a deep structure. In such a scenario, I need to manually perform a depths-first-search by opening dozens of submodules.

This would also be useful for tags.

Many projects using strict semantic versioning will produce one-three tags per week leading to around >100 tags per year.

I could imaging:

  • pattern / regexp based filtering
  • by date (e.g. last 2 months)
  • understanding semantic versioning (in branches and tags) and allowing filters like 2.3.* or >=3.7

I have no opinion about manual coloring remotes, but it would be nice to have several remote colors.

Maybe, it can be implemented like graph coloring styles.

As a maintainer for an open source project, I have multiple remotes in my repository:
- (local branches)

- main repo on github

- fork on github for my company

- company internal version


While most commits have on parent and one child, ...


  • ... many commits will have 2 parent => merge
  • ... you might have multiple parents => octopus merge (rare)
  • ... you will find many with multiple children => branches

@griscom

Shouldn't we request for a commit1..commit2 diff based on the submodule update in the parent?

What if the following view of a submodule update wouldn't just show IDs, Authors and Dates, but also a diff button to open the submodule in a diff window? Maybe the view could also present a preview what files have changed.