Hi, 686526b84cba 

Thanks for comment. I admit that in 4.2.4 it still may occur in one case (when your repo is being reopened after reopening Sourcetree, other words repo window restoration mechanism).

But, good news, we already added corresponding enhancements which intended to cover this case too. These enhancements will re available in the next release.

Thanks and glad to hear you was able to resolve your issue using provided workaround. 

Hi Raman, just for information: After upgrading from 4.2.1 to 4.2.4 I had this issue too. Using your workaround (removing and re-adding the root repo from Sourcetree) fixed it for me.
Thank you.

The fix for this issue is available in Sourcetree 4.2.4.
You could upgrade your Sourcetree via "Check For Updates" feature or directly download it from official website.
Thanks.

Hi Raman,

I can confirm that your work-around worked for me.

I'm curious - was the issue related to the case differences in the root path?

In any event - I'm off and running again. Thanks so much!

Paul.

Hi, c4d2590dc025 

Ok first good news. Finally I was able to repeat the same behaviour. We achieved this due to your detailed comments which you provided for every question. Thank you so much for proactive position

Second good news is it looks like I have simple workaround for you which will help you to continue working with your submodules using Sourcetree 4.2.3. Workaround idea is to remove your root repo from Sourcetree and add it back. Below are steps how to do this:

1. Open Sourcetree.

1. Find your root repo in Sourcetree’s repository browser window. When I'm saying root repo I mean repo where submodules are located. I looks like for you it's "braincloud-deploy".

1. Select this repo → right mouse click → Delete

1. In the appeared dialog choose “Remove Bookmarks“. It will remove bookmark only from Sourcetree. Repository still will be presented in filesystem.

1. Wait when repo disappeared from repository browser.

1. Add this repo to Sourcetree again. You could do it by drag&drop your repo root folder to Sourcetree’s repository browser window OR using “New…->Scan Directory“ functionality.

1. your submodules should work now

And in the end I want to say that I created internal issue for resolving this bug. I hope we will be able to deliver fix in one of the future releases.

Also, please, let me know, if workaround works for you.

Thanks!

Hi Raman,

Here's the contents of that .git file in settings-internal is:
gitdir: ../.git/modules/settings-internal

The root is called "braincloud-deploy". The "braincloud" dir higher up in my path is just a folder on my system to collect the independent braincloud projects. It isn't a git repo itself.

I am able to navigate properly to the relative path

So the path I end up in is /Users/winterhalder/bitheads/projects/braincloud/braincloud-deploy/.git/modules/settings-internal

And the [core] contents of config - including the "worktree" property is:

[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
ignorecase = true
precomposeunicode = true
worktree = ../../../settings-internal

(And note - cd'ing to that relative path does get me back into the proper directory)

I hope that helps (and that I followed your instructions properly).

And no problem with the detailed instructions - I'm happy that you are looking into it! And I appreciate that this is tough to track down. It is good to know that something changed in processing the "worktree"

Certainly the five ".." in the paths SourceTree 4.2.3 is calculating match the fact that "braincloud-deploy" is 5 levels deep.

I wonder if it might have something to do with case.

Although at the command line, my path to braincloud-deploy looks like this:
/Users/winterhalder/bitheads/projects/braincloud/braincloud-deploy

When viewed through MacOS finder - the path directories look like this:
/Users/winterhalder/bitHeads/Projects/brainCloud/braincloud-deploy

(Note the capitals in bit"H"eads, "P"rojects, brain"C"loud...)

You'll not that the subrepo has ignorecase=true - and I just checked - ignorecase = true is also specified in the root repo.

But maybe somewhere in your code you're checking paths and you aren't lowercase everything before the compare - maybe? (Just a thought)

Hi, c4d2590dc025 

Analysed you comments and took into account all your notes. Unfortunately I'm still unable to repeat this.

It looks like I have one more question. All of this makes me think that it could be some issue inside Sourcetree functionality which is processing core.worktree setting inside gitconfig in some incorrect way.

Could you please do the following:

1. Please, get one of the your "bugged" submodules. Let's take "settings-internal" submodule from your last screenshot as example. Navigate it inside Finder and find ".git" file inside root of this submodule and open it.
2. This ".git" file should contain "gitdir: " entry. Could you please provide this entry here to comments?
3. A little explanation. This path is kind of reference to real git config file for this submodule, located inside ".git/modules..." folder of your "root" repository. As I understand your root repository is "braincloud" (maybe I'm wrong).
4. So, get the path contained inside "gitdir:" entry. It will be relative path. Could you please follow this relative path, starting from "settings-internal" submodule root. By following this path you will reach real config for your submodule. I think finally you will reach similar directory: "~/bitheads/projects/braincloud/.git/modules/braincloud-deploy/modules/settings-internal".
5. Please, find "config" file here and open it.
6. In this config file, please find "worktree" entry. Could you please provide this entry here to comments?

Sorry for such a big guidance, but I really could not repeat the same behaviour. Maybe it's because there are some additional condition required. I'm asking you to provide this info, because there was only one change between 4.2.1 and 4.2.3 that potentially may affect submodules and this change is related to code that is processing "worktree" entry from git config file. So, I think when you will provide requested info, we will have better understanding on this (I hope).

Thanks, looking forward to your reply.

c4d2590dc025 

Thanks for such a detailed comments. I'll try to analyse them and will return back to you with some results.

For what it's worth - I don't think it has anything to do with the 3rd level sub-repos.

One of my sub-repos - "settings-misc" - doesn't have the "kustomize" repos linked under it - and it still has this problem.

I'll note that none of my sub-repos have been linked directly into sourcetree - i.e. i can't get to "settings-internal" directly - I always have to go through "braincloud-deploy" and then to "settings-internal". <- just in case that makes a difference setup-wise?

And to further confirm - here's a "git status" for my "settings-internal" sub-repo...

❯ git status
On branch master
Your branch is behind 'origin/master' by 10 commits, and can be fast-forwarded.
(use "git pull" to update your local branch)

Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git restore <file>..." to discard changes in working directory)
modified: kube/braincloud-internal-cluster/dev-internal/.python-version

no changes added to commit (use "git add" and/or "git commit -a")

(Note that the path seems fine)

But here's what I see in SourceTree - https://app.screencast.com/0nPvMbn91HFcq