On 7. Nov 2018, at 13:12, Stefan Daschek stefan@daschek.net wrote:

Using TextMate 2.0-rc.14

For me works - using TextMate 2.0-rc.15

-Hans

Am 07.11.18 um 13:38 schrieb Jacob Carlborg:

...

On 7 Nov 2018, at 13:24, Hans-Jörg Bibiko bibiko@shh.mpg.de wrote:

...

On 7. Nov 2018, at 13:12, Stefan Daschek stefan@daschek.net wrote:

Using TextMate 2.0-rc.14

For me works - using TextMate 2.0-rc.15

Same here.

Hm, on my other machine (TextMate 2.0-rc.15) it also doesn’t work. Both machines have similar but not 100% identical configurations (both are still using 10.13 High Sierra, by the way).

So it seems this is somehow related to my setup - any hints on how to debug this?

Stefan

I’ve seen this behaviour (rc.15 on Mojave and rc.14 on High Sierra) but only with a project that I’ve got stored on my iCloud drive. Which seems a bit odd. I don’t think it can be that the .git folder isn’t synching, because like Stefan says, all the Git bundle commands work fine, and the icons have the right badges in the file browser.

(Also odd, but off-topic, on my iMac running High Sierra, check for updates tells me I am up to date on rc14, but on my laptop running Mojave it tells me I am up to date on rc15.)

On 7 Nov 2018, at 12:12, Stefan Daschek stefan@daschek.net wrote:

Today I noticed that clicking the SCM icon in the bottom right of the file browser no longer does anything (it used to filter the view to include only those files with a specific SCM status). Maybe this is related to the recent changes in the file browser?

Everything else regarding SCM (using Git in my case) still works as expected, including the SCM badges on the icons in the file browser.

Using TextMate 2.0-rc.14

Cheers, Stefan

---

textmate mailing list textmate@lists.macromates.com https://lists.macromates.com/listinfo/textmate

Am 10.11.18 um 08:18 schrieb Allan Odgaard:

On 9 Nov 2018, at 23:28, Nigel Chapman wrote:

I’ve seen this behaviour (rc.15 on Mojave and rc.14 on High
Sierra) but only with a project that I’ve got stored on my iCloud
drive. Which seems a bit odd. I don’t think it can be that the
.git folder isn’t synching, because like Stefan says, all the Git
bundle commands work fine, and the icons have the right badges in
the file browser.

When you click the SCM button, is it a no-op or does the file browser show an empty list of files? And if the latter, does the header say anything?

For me, it’s a no-op.

Also, can you try open SCM status via File Browser menu (SCM Status ⇧⌘Y)? Just to be sure the issue is not just with the button, although that it’s a single project seems to indicate that it is not.

Same effect as clicking the button: It’s also a no-op.

I tried with even more of my projects and it turns out that only some projects are affected. Currently it looks like the bug occurs in projects where Git submodules are present. Interestingly, both the “parent” project as well the submodules themselves seem to be affected. Projects not using submodules seem to work normally.

S.

For me on rc.14, it’s not a no-op, it toggles between the file list and an empty pane with no title. High Sierra 10.13.6 here.

On 10 Nov 2018, at 23:15, Marc Wilson wrote:

For me on rc.14, it’s not a no-op, it toggles between the file list and an empty pane with no title. High Sierra 10.13.6 here.

That’s a directory which has a repository?

And you say no title, can you capture this?

I.e. with a folder that has no repository, it should show empty pane but with a header like this:


On 12 Nov 2018, at 04:37, Allan Odgaard mailinglist@textmate.org wrote: Did it work prior to the file browser update?

It certainly worked in the past. I can’t definitely pin it down to the file browser update, as I only returned to working on this project recently. I originally thought it must have happened when I installed Mojave, but then I found out that the same thing is going on on my other machine which still has High Sierra, so the file browser update seems the likeliest time at which it stopped working.

Also, where is this project on disk? Are you using mate /path/to/project to open it? Or possibly the file browser’s “Go to Folder…”.

This is on the iCloud drive volume, which I see in the sidebar of the open dialogue. It’s not in a Textmate container. The actual folder is inside

~/Library/Mobile Documents/com~apple~CloudDocs/

I usually open this project with the Favourite Projects dialogue, but it’s all the same whether I use that, the File>Open command or mate from inside terminal.

I tried a few extra things, which only confused matters further. If I open any folder on the iCloud drive, the SCM button does not work, it’s a no-op, whether there's a repo or not. If I open any folder that was originally created on the local drive, it works as expected – if there’s a Git repo it shows the uncommitted changes and untracked items, if not, the “no status” thing. But, if I copy one of the folders off the iCloud drive to the local drive, the SCM button doesn’t work. Same whether I copy the whole folder or create a new folder and copy all the files. (This is all done in the Finder, I haven’t tried copying in terminal.) But I can’t see any unexpected hidden files in these folders.

I couldn’t see anything in the system logs that might correspond to something going wrong when I click the button.

If it was just me and my iCloud drive, I’d say that it was an edge case that you needn’t bother about, but these other reports that don’t seem to have anything in common are perhaps a bit concerning.

And thanks for reviving my request about the auto-hiding file browser.

All the best

Nigel

On 12 Nov 2018, at 17:22, Nigel Chapman wrote:

I tried a few extra things, which only confused matters further. If I open any folder on the iCloud drive, the SCM button does not work, it’s a no-op, whether there's a repo or not. If I open any folder that was originally created on the local drive, it works as expected – if there’s a Git repo it shows the uncommitted changes and untracked items, if not, the “no status” thing. But, if I copy one of the folders off the iCloud drive to the local drive, the SCM button doesn’t work. Same whether I copy the whole folder or create a new folder and copy all the files. (This is all done in the Finder, I haven’t tried copying in terminal.) But I can’t see any unexpected hidden files in these folders.

In v2.0-rc.18 I added an explicit alert dialog for when a) no version control information is found, or b) when version control is found, but has been explicitly disabled for the folder (as we do e.g. for the home folder due to performance issues).

Let me know if this alert is triggered, or if the button is still sometimes a no-op.

On 14 Nov 2018, at 16:31, Stefan Daschek wrote:

For me it’s still a no-op in some projects – and it may still be related to Git submodules: For the handful of projects I tried, it worked correctly in those without submodules, and didn’t work in those containing submodules (regardless whether the project folder was the parent repository or one of it’s submodules).

The TextMate source itself uses submodules, can you try clone that repository and see if that works?

git clone --recursive https://github.com/textmate/textmate.git

You were on to rc19 by the time I updated. For that version, I now get this behaviour:

Folder on local drive, with Git repo: works as it should, with changed/untracked files displayed in file list. Folder on local drive, no Git repo: new alert is displayed, the file list does not change, Folder on iCloud drive, with Git repo: button is still a no-op Folder on iCloud drive, no Git repo: new alert is displayed, the file list does not change. (Previously, this case was a no-op, too).

In v2.0-rc.18 I added an explicit alert dialog for when a) no version control information is found, or b) when version control is found, but has been explicitly disabled for the folder (as we do e.g. for the home folder due to performance issues).

Let me know if this alert is triggered, or if the button is still sometimes a no-op.

---

textmate mailing list textmate@lists.macromates.com https://lists.macromates.com/listinfo/textmate

Am 22.11.18 um 09:23 schrieb Allan Odgaard:

I found the issue: Spaces in |/path/to/repository/|

Ah, this should explain it! Accidentally, all the repos I tested that contained submodules have paths containing spaces, and those without submodules have paths without spaces … so in the end this bug was totally unrelated to submodules 🤷‍♂️

s.