[Enhancement] Files pane UI layering

[ofuncke]

The files pane, which is global, is currently positioned as 3rd tab within the commit pane. It should be positioned more prominently, e.g. as a separate dockable pane or fixed under the branches tree.

[love-linger]

FILES panel shows all files in the revision of selected commit, not the files in current worktree

[ofuncke]

Sorry, forgot to mention I'm using it on the repo's main branch.

[love-linger]

I mean it does not show files in current file-system. It displays the files in the snapshot of the revision (selected commit), which is equivalent to git ls-tree -r <commit_sha>.

It can be seen from this that the content of this panel depends on the selected commit, not global as you said.

[goran-w]

@ofuncke The per-commit FILES view is relevantly positioned as a tab next to INFORMATION and CHANGES for the selected commit, IMHO.

However, if you're looking for a "Working Copy Explorer" / "Local Files" type of view, I'm (locally) planning a future PR for such a thing. It would be a new "main" page - along with HISTORY, LOCAL CHANGES, STASHES there would be a 4th selectable view for LOCAL FILES (or similar)... This view would be similar-to / based-on the commit-FILES view, but based on git ls-files instead of git ls-tree.

(I'm coming from Plastic SCM / Unity Version Control, which had a "Workspace Explorer" view that shows the current state of the files in the working copy.)

[love-linger]

In fact, if you only need to manage the files of the current worktree (not related to content, only for adding, moving, or deleting), please use the Open in File Browser feature. If you need to edit the files of the current worktree, you can configure an external editor and use it to open the files.

There's no plan to add a built-in file browser

[goran-w]

There's no plan to add a built-in file browser

Let's not be so dismissive / disheartening for once, shall we? 😉🙄

I will gather arguments for why this is a good idea, and we can discuss it once I'm ready to "take the fight". 🥺🤗

[love-linger]

At present, the following requirements will not be added to the development plan. - Third-party hosting platform-specific service integration. It is recommended to use custom action to call the cli tools provided by it - Built-in terminal. It is recommended to use your favorite terminal applications. - Built-in file management. It is recommended to use the file management application provided by the system. - Built-in code editor. It is recommended to use your favorite code editor

[goran-w]

I agree with the first two points, but the last two points are more debatable.

Of course, SourceGit should not aim to be a full-featured code editor. However, it would be extremely useful if it was possible to make simpler editing in the Diff view, before committing changes. This is something we had in Plastic SCM, and is now a bit of a let-down since not available inside SourceGit. Also, it's a missed opportunity since the Text Diff view is based on Avalonia's full-featured text-editing component...

Here is an example where I'm editing inside the Diff view (under Pending Changes) in Plastic SCM:

[goran-w]

As for file-management, there is already a file-tree viewer for "historic" commits in SourceGit, so it would be very useful to have something similar for the "current" Working Copy contents. (Not a fully-fledged file explorer, but rather one that is much more focused on Git operations / status on the current worktree-state.)

The lack of such a "Working Copy files" view (showing all local files, not just Local Changes) is another of the "major" let-downs we identified when migrating from Plastic SCM to (Source)Git...

Here is a screenshot from the "Workspace Explorer" in Plastic SCM (after connecting a Plastic-repo to my GitHub fork of SourceGit via the Plastic SCM "GitSync" feature) :

And here is an example of a context-menu for a file in that view:

(Of course, these Plastic-features are not mapping exactly to Git features, but this should at least give a rough indication of what could be done.)

There's also a Details-panel which is somewhat similar to the file-viewer panel in FILES on SourceGit:

[love-linger]

SourceGit has provided a way to directly use these external tools to open repo or files. I think this is enough. SourceGit does not intend to copy any other Git clients, even if most of the features are inspired by these software. What's more, one of the reasons for writing this app is that some clients are too bloated.

[goran-w]

The two features I'm discussing would not add considerable "bloat". Editing in the Diff view would be largely "transparent", and if we choose not to use the Local Files view it only adds a small footprint to the overall UI (while offering something very similar to the existing FILES view that can be very useful to those who wish for it).

[goran-w]

SourceGit does not intend to copy any other Git clients, even if most of the features are inspired by these software.

Speaking of which - the UI layouts of SourceGit vs git-Fork are VERY similar, so who's copying who? 👀😅

[goran-w]

BTW - The very basic Git commands git rm and git mv can't currently be directly applied to unchanged files inside SourceGit, since there is no view of the full current Working Copy. We'd have to call these commands from the terminal, or delete/move/rename a file from disk outside SourceGit, to make the desired modification appear among Local Changes.

Also, there are other commands that require a local path, like "add submodule", which would benefit from being performed by context menu on a specific point in the local file-tree (as an alternative way of performing the functionality).