feat(Repo Title): Append root repo to description of submodule #12156

mstv · 2025-01-21T20:57:01Z

Implements
#12144 (comment)

Proposed changes

RepositoryDescriptionProvider.Get:

no change for normal repos
for submodule: append description / name of its root superproject
affects GE title bar and recent .gitext files for Window Jump List

Screenshots

Before

After

Test methodology

manual

Merge strategy

I agree that the maintainer squash merge this PR (if the commit message is clear).

✒️ I contribute this code under The Developer Certificate of Origin.

to submodule description

RussKie

I can't say I find this change exciting... +0

Could you please add tests for the altered functionality.

gerhardol · 2025-01-23T22:20:38Z

If there is a description for the top level repo, it is repeated

If the top level has no description, it is the name of the parent directory. That would be helpful for those that clone to "project dirs". Not sure I like it myself..

A submodule where parent has a description should use that, not dir name

The second should be the top repo (description), that is descriptive. Multiple clones in multi level clones will have the same parent

I like this and it would be helpful as option in the dropdown menu (I really dislike the change some releases ago, I can never find the repo anymore and have to do to the dashboard.

I can't say I find this change exciting... +0

If you only have one clone of each repo it adds no value, but if you have many clones in different levels it helps

feat(Repo Title): Append root superproject to submodule description

gerhardol · 2025-01-24T22:35:49Z

The second level for submodules is still the top level parent foldername
I suggest this is set to the description if it exists, otherwise top level dir name

So first is desc or dirname for current repo
Second is parent dir for top, desc or name for others

mstv · 2025-01-25T11:35:35Z

So first is desc or dirname for current repo

👍

Second is parent dir for top, desc or name for others

I would rather be consistent and do not add more complexity, i.e.
Second is desc or dirname for top / root repo

And that is how the current code should already work (and does for me in my test repo).

RussKie · 2025-01-25T13:25:47Z

src/app/GitCommands/UserRepositoryHistory/RepositoryDescriptionProvider.cs

-            }
+            DirectoryInfo repositoryDirInfo = new(repositoryDir);
+            return GetRootProjectDirInfo(repositoryDirInfo) is DirectoryInfo rootProjectDirInfo
+                ? $"{GetShortName(repositoryDirInfo)} - {GetShortName(rootProjectDirInfo)}"


Suggest swapping the strings and use / instead of - to makes it look neater.

Suggested change

? $"{GetShortName(repositoryDirInfo)} - {GetShortName(rootProjectDirInfo)}"

? $"{GetShortName(rootProjectDirInfo)}/{GetShortName(repositoryDirInfo)}"

That would add the important info last, so this would be less readable. This is also visible in the taskbar, the real repo would not be visible. This should also be used in shortcuts (and would like it in the dropdown menu, even worse).

Suggest swapping the strings and use /

Would be clearer. I considered and scrapped that for the same as reason as Gerhard.

❔

Suggested change

? $"{GetShortName(repositoryDirInfo)} - {GetShortName(rootProjectDirInfo)}"

? $"{GetShortName(repositoryDirInfo)} [{GetShortName(rootProjectDirInfo)}]"

"submodule [super repo] (branch of submodule)"

or else - although I want to avoid translation -

Suggested change

? $"{GetShortName(repositoryDirInfo)} - {GetShortName(rootProjectDirInfo)}"

? $"{GetShortName(repositoryDirInfo)} in {GetShortName(rootProjectDirInfo)}"

"submodule in super repo (branch of submodule)"

or

Suggested change

? $"{GetShortName(repositoryDirInfo)} - {GetShortName(rootProjectDirInfo)}"

? $"{GetShortName(repositoryDirInfo)} <{GetShortName(rootProjectDirInfo)}"

To me a submodule is a part of a super-module, hence "gitextensions/ConEmu" feels more logical compared to "ConEmu (gitextensions)"...

In the taskbar, one can see the first chars only.
(As Gerhard has already stated), if one runs several GE instances with the submodules of the same repo, they could not be distinguished (without hovering and waiting for Windows to start to show some information some day).
(One of the first actions on a fresh Windows installation is to set taskbar grouping to "never".)

My 2ct: I vote for "conemu < gitextensions (branch) - Git Extensions" as GE title.
(I have no big interest in this feature myself. Luckily, I do not need to work with submodules very often. I just wanted to be nice by mitigating the effect of the bugfix #12144).

Regarding "two major styles of top level repo cloning":
If one runs multiple instances with the same top repo name in different project folders, I vote for adapting the description files or for using unique folder names.
Otherwise, the GE instances would need to know each other. Or the list of recent repos would need to be parsed for duplicate names. Such a complex feature would definitely require a separate PR.
I do not want to get "conemu < Build ..." for "D:\Build\gitextensions" just because I created a test clone "gitextensions" in a temp folder.

I have noticed the lack of unit tests. But it would require to create a nested repo structure in the test setup - which bears no proportion for me in this case.

My 2ct: I vote for "conemu < gitextensions (branch) - Git Extensions" as GE title.

I think we could display "Git Extensions" only when we are at the dashboard but remove it when a repo is loaded. Because it takes some place, bring no value (as everyone knows he is using gitextensions) and sometimes takes time to read and brain effort.

"Git Extensions"

Most Win apps even File Explorer are appended to the title, so I suggest we keep that

My 2ct: I vote for "conemu < gitextensions (branch) - Git Extensions" as GE title.

Will someone believe the branch is for the toprepo (or parent dir)?
Then "conemu [gitextensions] (branch) - Git Extensions" may be clearer.

I have noticed the lack of unit tests. But it would require to create a nested repo structure in the test setup - which bears no proportion for me in this case.

Agree

Regarding "two major styles of top level repo cloning": ...

No this will not be unique for all, that is impossible.
I work a lot with submodules and #12144 make switching more difficult (as there will be too many repos in the list).
Always parent dir is no improvement to me and toprepo is an improvement.

Will someone believe the branch is for the toprepo (or parent dir)?

Maybe - but only for short time. I want to keep it simple.

RussKie · 2025-01-25T13:28:40Z

It'd be great to add tests as well. Doesn't look like we have any for this class... :(

gerhardol · 2025-01-25T15:21:18Z

Second is parent dir for top, desc or name for others

I would rather be consistent and do not add more complexity, i.e. Second is desc or dirname for top / root repo

And that is how the current code should already work (and does for me in my test repo).

Top repo is more useful where utility submodules are shared both for clones with separate names and project with multiple clones. Parent dir for top level has much less info also in project style cloning.
Not much complexity as I see it.

mstv · 2025-01-25T16:42:58Z

Parent dir for top level has much less info also in project style cloning.

I do not get what you mean. The description of the top level repo is displayed or its folder name as fallback.
That is what you requested in:

The second should be the top repo (description), that is descriptive. Multiple clones in multi level clones will have the same parent

gerhardol · 2025-01-25T22:12:30Z

Parent dir for top level has much less info also in project style cloning.

I do not get what you mean. The description of the top level repo is displayed or its folder name as fallback. That is what you requested in:

The second should be the top repo (description), that is descriptive. Multiple clones in multi level clones will have the same parent

If all modules including submodules are named the same, you do not need this change, then the name is unique.

I see two major styles of top level repo cloning:

unique name of the top cloned folder, as well as worktree. the folders have unique names. This is my primary preferred way.
clone the top repos in one folder for related projects, like oldrelease1.0, nextRelease. There may be several similar type of top-clones with similar subrepos in this setup. Then the parent to the top folder clone name is (maybe) unique. I use this for Win vs WSL distros (multiple) and some special scripting.

submodules on the other hand cannot be changed directly (only with description file). This is my main issue, how to see where a 'util' repo is used.
In my case there can be multiple 'util' in one toplevel projects even, when several standalone top level projects are added to a new top level project, but that is slightly overkill here.

The latest implementation supports the case where there are project clones with clones that have all unique submodules. The display for multiple submodules in one parent folder is better with displaying the toplevel name, this is a more important case for me, it is like 90% of the value.

gerhardol · 2025-02-02T23:17:02Z

src/app/GitCommands/UserRepositoryHistory/RepositoryDescriptionProvider.cs

+                DirectoryInfo? rootProjectDirInfo = null;
+                for (DirectoryInfo? superProjectDirInfo = repositoryDirInfo.Parent; superProjectDirInfo?.Exists is true; superProjectDirInfo = superProjectDirInfo.Parent)
+                {
+                    if (GitModule.IsValidGitWorkingDir(superProjectDirInfo.FullName))
+                    {
+                        rootProjectDirInfo = superProjectDirInfo;
+                    }
+                }
+
+                return rootProjectDirInfo;


My proposal to make this PR really useful, to have topmodule info for submodules

Suggested change

DirectoryInfo? rootProjectDirInfo = null;

for (DirectoryInfo? superProjectDirInfo = repositoryDirInfo.Parent; superProjectDirInfo?.Exists is true; superProjectDirInfo = superProjectDirInfo.Parent)

{

if (GitModule.IsValidGitWorkingDir(superProjectDirInfo.FullName))

{

rootProjectDirInfo = superProjectDirInfo;

}

}

return rootProjectDirInfo;

DirectoryInfo? rootProjectDirInfo = null;

DirectoryInfo? topProjectDirInfo = null;

for (DirectoryInfo? superProjectDirInfo = repositoryDirInfo.Parent; superProjectDirInfo?.Exists is true; superProjectDirInfo = superProjectDirInfo.Parent)

{

if (GitModule.IsValidGitWorkingDir(superProjectDirInfo.FullName))

{

topProjectDirInfo = rootProjectDirInfo;

rootProjectDirInfo = superProjectDirInfo;

}

}

return (topProjectDirInfo is null || topProjectDirInfo == repositoryDirInfo) ? rootProjectDirInfo : topProjectDirInfo;

Edit: Not working for top repo

Implemented - with "root project / repo" and "root submodule".
Due to lack of usage, it is not obvious to me why this is the most useful combination.
How would you describe this behavior (without naming one "root project" and the other "top project"?

I pushed something that works, with updated tests
There is one trap though, if the project dir has a .git repo but the toprepo is not a submodule, the project repo will be set as top module (but that is occasionally how you want it)
If the commit is rejected, I am OK with the functionality as is, it is an improvement.

Description:
Describe the current repository in the title bar and jumplist not just with the directory name (or the description, if that exists) but also the name (or description) for the topmodule (for submodules) or the parent "project" directory (for the topmodule).
With this it is possible to identify topmodules cloned with identical names to multiple directories as well as similar utility submodules in multiple topmodule clones.

DirectoryInfo rootSubmoduleDirInfo = repositoryDirInfo; DirectoryInfo? rootProjectDirInfo = repositoryDirInfo.Parent; for (DirectoryInfo? superProjectDirInfo = repositoryDirInfo.Parent; superProjectDirInfo?.Exists is true; superProjectDirInfo = superProjectDirInfo?.Parent) { if (superProjectDirInfo is not null && isValidGitWorkingDir(superProjectDirInfo.FullName)) { rootSubmoduleDirInfo = superProjectDirInfo; rootProjectDirInfo = superProjectDirInfo.Parent; } } return rootSubmoduleDirInfo == repositoryDirInfo ? rootProjectDirInfo : rootSubmoduleDirInfo;

(sorry, I forgot about this PR)

I pushed something that works, with updated tests

We should have discussed this using examples from the beginning...

We should have discussed this using examples from the beginning...

yes... but I was not sure what I wanted, I saw the current as a kind of feature. But sub<top is better as well as top - parent

submodule < topmodule
is clear I believe

Question is for topmodule
I think I prefer folder-for-top to current letter:folder as in the PR
So this is fine for me with the letter removed

Some examples

deep structure, ok

repo in drive root c: double

wsl - \ is not much info

not this PR, same in release - if switching from Linux while loading the repo is not updated in title or grid

A not major issue is that detection is not really gitrepo but something that looks like a gitmodule. I had a dummy repo in my main clone folder, it was registered as a topmodule.
I guess that is my problem though.

The drive letter / double backslash (without '<' separator) emphasizes that it is not a repo but the parent folder.
The drive info is the only useful information from the parent folder to me. I would rather add a config to not display the parent folder at all.

I would rather add a config to not display the parent folder at all.

In that case skip the extra info for topmodules for now, just extra for submodules.
I guess this is basically reverting two last commits?

GE has too many options already (even if I personally like them) and we do not get the "why do you change" questions.
This is an improvement especially for submodules, so take the most important aspect of this PR for now.

feat(Repo Title): Append root repo / parent folder to description of submodule / repo, respectively

feat(Repo Title): Append root repo for submodule

Copilot

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (1)

src/app/GitCommands/UserRepositoryHistory/RepositoryDescriptionProvider.cs:86

The loop condition in GetShortName might exit prematurely if dirInfo becomes rootRepositoryDirInfo but dirInfo.Parent is still not null. Consider revising the condition to ensure the loop behaves as intended.

while (dirInfo != rootRepositoryDirInfo && dirInfo.Parent is not null && _uninformativeNameRegex.IsMatch(dirInfo.Name) && !isValidGitWorkingDir(dirInfo.Parent.FullName))

feat(Repo Title): Append superproject

dda5cad

to submodule description

mstv self-assigned this Jan 21, 2025

RussKie reviewed Jan 23, 2025

View reviewed changes

fixup! feat(Repo Title): Append superproject

b21fe77

mstv changed the title ~~feat(Repo Title): Append superproject to submodule description~~ feat(Repo Title): Append root superproject to submodule description Jan 23, 2025

amend! feat(Repo Title): Append superproject

145d40a

feat(Repo Title): Append root superproject to submodule description

RussKie reviewed Jan 25, 2025

View reviewed changes

gerhardol reviewed Feb 2, 2025

View reviewed changes

fixup! amend! feat(Repo Title): Append superproject

0b39c3d

mstv changed the title ~~feat(Repo Title): Append root superproject to submodule description~~ feat(Repo Title): Append root repo / parent folder to description of submodule / repo, respectively Feb 13, 2025

mstv added 4 commits February 13, 2025 21:19

amend! feat(Repo Title): Append superproject

542ef6c

feat(Repo Title): Append root repo / parent folder to description of submodule / repo, respectively

fixup! amend! feat(Repo Title): Append superproject

7d5381e

amend! fixup! amend! feat(Repo Title): Append superproject

9ac9b46

feat(Repo Title): Append root repo for submodule

fixup! amend! fixup! amend! feat(Repo Title): Append superproject

abdb0e8

mstv changed the title ~~feat(Repo Title): Append root repo / parent folder to description of submodule / repo, respectively~~ feat(Repo Title): Append root repo to description of submodule Feb 15, 2025

RussKie requested a review from Copilot February 16, 2025 00:33

Copilot AI reviewed Feb 16, 2025

View reviewed changes

gerhardol approved these changes Feb 16, 2025

View reviewed changes

mstv merged commit a5ca835 into gitextensions:master Feb 18, 2025
3 of 4 checks passed

mstv deleted the feature/superproject branch February 18, 2025 19:31

mstv added this to the v5.3 milestone Feb 18, 2025

	? $"{GetShortName(repositoryDirInfo)} - {GetShortName(rootProjectDirInfo)}"
	? $"{GetShortName(rootProjectDirInfo)}/{GetShortName(repositoryDirInfo)}"

	? $"{GetShortName(repositoryDirInfo)} - {GetShortName(rootProjectDirInfo)}"
	? $"{GetShortName(repositoryDirInfo)} [{GetShortName(rootProjectDirInfo)}]"

	? $"{GetShortName(repositoryDirInfo)} - {GetShortName(rootProjectDirInfo)}"
	? $"{GetShortName(repositoryDirInfo)} in {GetShortName(rootProjectDirInfo)}"

	? $"{GetShortName(repositoryDirInfo)} - {GetShortName(rootProjectDirInfo)}"
	? $"{GetShortName(repositoryDirInfo)} <{GetShortName(rootProjectDirInfo)}"

Uh oh!

feat(Repo Title): Append root repo to description of submodule #12156

feat(Repo Title): Append root repo to description of submodule #12156

Uh oh!

Conversation

mstv commented Jan 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Proposed changes

Screenshots

Before

After

Test methodology

Merge strategy

Uh oh!

RussKie left a comment

Choose a reason for hiding this comment

Uh oh!

gerhardol commented Jan 23, 2025

Uh oh!

gerhardol commented Jan 24, 2025

Uh oh!

mstv commented Jan 25, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RussKie commented Jan 25, 2025

Uh oh!

gerhardol commented Jan 25, 2025

Uh oh!

mstv commented Jan 25, 2025

Uh oh!

gerhardol commented Jan 25, 2025

Uh oh!

gerhardol Feb 2, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gerhardol Feb 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

mstv commented Jan 21, 2025 •

edited

Loading

gerhardol Feb 2, 2025 •

edited

Loading

gerhardol Feb 11, 2025 •

edited

Loading