Jarred-Sumner / git-peek

git repo to local editor instantly
MIT License
722 stars 17 forks source link

macOS: problems on Big Sur (Intel) & BBEdit #22

Open JayBrown opened 3 years ago

JayBrown commented 3 years ago

So git-peek didn't work as expected with BBEdit. Config file ~/.git-peek has EDITOR=BBEdit --wait

It was working fine in iTerm, but as soon as I use the Firefox extension via the git-peek app, it failed. What I noticed was the following: the code signature of git-peek.app was broken, and it's not possible to apply a new signature, because git-peek-shim was in the wrong place within the bundle.

So I moved that file to ./Contents/MacOS/git-peek-shim, then changed its editor line to export EDITOR="BBEdit", then changed ./Contents/Resources/Scripts/main.scpt to

on open location this_URL
    try
        set innerCmd to "/Users/USER/Applications/git-peek.app/Contents/MacOS/git-peek-shim " & quoted form of this_URL & " &> /usr/local/var/log/git-peek &"
        do shell script innerCmd
    on error errMsg
        display dialog errMsg
    end try
end open location

i.e. changed the path of the variable innerCmd, whereas "USER" is substituted for my actual username, of course… then code-signed the app again, which finally worked, because git-peek-shim was now in a proper nested location. (Note: a broken signature might cause problems on Big Sur on arm64 macOS.)

Now, running git-peek via the Firefox extension opened BBEdit alright, but after the repo downloaded, it didn't show & was colored red, which in BBEdit means that a file has been deleted, in our case that the repo was deleted immediately after download.

How do I solve this problem?

git-peek via iTerm

snap1

git-peek via Firefox extension

snap2

Jarred-Sumner commented 3 years ago

the code signature of git-peek.app was broken, and it's not possible to apply a new signature, because git-peek-shim was in the wrong place within the bundle.

I didn't know that executable files have to go in a particular place within the .app folder. Thanks for that. I updated the register script to write to that location instead.

Now, running git-peek via the Firefox extension opened BBEdit alright, but after the repo downloaded, it didn't show & was colored red, which in BBEdit means that a file has been deleted, in our case that the repo was deleted immediately after download.

Just pushed 1.3.18 which fixes this for BBEdit. From me manually testing, it seems to work however for some reason it opens in the background instead of the foreground when coming from the extension. I'm not sure if there's a CLI argument I can pass it that tells it to open in the foreground – happy to add it if you know of it/can link to some docs that show their CLI arguments. When I say "background", I just mean it doesn't gain focus.

If you run this, it should update:

brew upgrade git-peek

Closing but feel free to re-open if you have any more issues with BBEdit/doesn't fix

JayBrown commented 3 years ago

Thank you. New problem now (still not working): git-peek apparently deletes the repo, and BBEdit still doesn't show anything. stdout tells me that git-peek "deleted repository".

snap

Though BBEdit does open in the foreground on my system. That's the default behavior of open, unless you specify -g (open in background) or -gj (open in bg & hidden), so I assume that the default in-foreground behavior should also apply to other open calls.

I noticed another problem with the code signature. Whenever changing anything that's nested in the .app bundle, e.g. writing the shim or changing the Info.plist, there needs to be a deep codesigning run at the very end, something like: codesign --force --deep --sign - foo… i.e. codesign shall always come last, and re-codesign shall occur after every config change by the user, if that entails a modification of nested bundle content.

Jarred-Sumner commented 3 years ago

It doesn’t use open unless it’s vim, but I probably should change it to use open instead of Node.js’ spawn thing.

I’m confused why this isn’t reproducing on my computer. If you haven’t, could you try re-running “git peek -r” after upgrading? Also, could you paste your $HOME/.git-peek if you’ve set that (excluding GITHUB_TOKEN)

I haven’t actually done the code signing thing. The tricky part is that the .app file is generated when you run git peek —register by compiling the .AppleScript. I could write a very tiny Swift app though that just runs the equivalent of the AppleScript and reads the location from the $HOME/.git-peek file On Sat, Feb 20, 2021 at 3:12 AM Joss Brown notifications@github.com wrote:

Thank you. New problem now (still not working): git-peek deletes the repo, and BBEdit still doesn't show anything. stdout tells me that git-peek "deleted the repository".

[image: snap] https://camo.githubusercontent.com/cda95919ac2558f07ba63c8ea2019af74164673be114de23abf3634534b851f3/68747470733a2f2f692e696d6775722e636f6d2f79646b316e6b702e6a7067

Though BBEdit does open in the foreground on my system. That's the default behavior of open, unless you specify -g (open in background) or -gj (open in bg & hidden), so I assume that the default in-foreground behavior should also apply to other open calls.

I noticed another problem with the code signature. Whenever changing anything that's nested in the .app bundle, e.g. writing the shim or changing the Info.plist, there needs to be a deep codesigning run at the very end, something like: codesign --force --deep --sign - foo… i.e. codesign shall always come last, and re-codesign should occur after every config change by the user.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Jarred-Sumner/git-peek/issues/22#issuecomment-782608201, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFNGS5AN5ZTXSVUKTQQPG3S76KKVANCNFSM4X5VNQYQ .