CodeLite with multiple Git repos in one workspace

[danielfdickinson]

First, I am quite impressed with CodeLite's look and feel, and it looks quite excellent for its main purpose (single-repo C/C++/Rust/etc projects), and fully intend to use it for that purpose.

As a note, I am currently using CodeLite 17.x from Debian 13 (trixie) rather than 18.2 due to issues with the apt repo signing key for the codelite apt repo (#3829), so my question may no longer relevant, once I can use that repo (or decide to build from source).

Now to the main point: I am looking to use CodeLite for doing development on OpenWrt, particularly on various packages and the packages repo and the applications for the luci web interface.

This involves working with multiple git repositories at the same time, which are not organized as git submodules (nor do I want to use submodules)[1]. I am also not certain if submodules would resolve this query in any event.

The problem I am seeing is that the Git plugin wants to operate based on a single git repo rooted at the top of the CodeLite workspace. I'm looking to be able to do view git logs, git blame, add commits, etc on the 'nearest .git' for the file I have open, or folder I have open in the workspace pane, or explorer view.

Is this possible with CodeLite, and I have just missed how with 17.0; or is possible with 18.2, or is not currently possible?

If not, then my search for my preferred configuration to replace VS Code for this particular use case continues. For CodeLite's main purpose I still intend to 'take test drive' with CodeLite, though.

Thank you for an awesome tool, regardless.

[1] I have an alpha version of a tools to pull down all the repositories in a useful 'repo workspace' at https://gitlab.com/dfd-web/firmware/openwrt-mirrors/openwrt-repotool, which I have working well with Visual Studio Code, but I want to move away from VS Code.

[eranif]

It can't be done atm.
It shouldn't be too hard to add this functionality. But it needs to be defined first.

For example:

• How is it going to work when committing a change? mainly when you use the keyboard accelerators like Ctrl-Shift-P -> git commit, to which repo should we commit?
• Does the view (modified files, un-tracked files) needs to be refreshed whenever we switch a file? that is belonged to a different repo? or do you expect a multiple repo view at the same time?

Once defined we can asses the effort needed.

[danielfdickinson]

Thank you for the clarification, and the questions.

I think changing view on every context switch could be 'expensive'. I also prefer the idea of everything from the workspace root (even if it is not a git repo itself) down being part of the 'git context', with, eventually, different ways of filtering that view (like by the repo, or even directory of the current active file).

To start, I think having every git repo in the root of the workspace as part of a 'tree' view would be the most useful. It might be easier to start with having lists of modified/untracked files per-repo in a big list with the repos being titles of the section. Likewise for commit lists.

Having a pop-out window (i.e. new frame) for a larger view of the git views could also be useful.

For commits via accelerator, I think a sensible start would be to work in the git context of the currently active file, with a selector in the status bar, to override.

In many ways, I think I would prefer a pop-out frame when wanting to manage all the repos rather than something like the VS Code sidebar.

In that case the 'Git' tab of the 'Output' pane could be context-sensitive (whether that context is chosen by the active file, or by some 'manual' action, I have no preference (and the 'manual' selection approach might be better from the 'principle of least surprise').

I'm not sure that helps. I will make an effort to take some time to map out a better definition, if you would like.

[eranif]

I will make an effort to take some time to map out a better definition, if you would like.

A mock screenshot(s) could be most helpful.

[danielfdickinson]

I've thought about it, and decide I've decided that this is not as useful / important as I was thinking.