- #Sublime merge build 1107 license how to#
- #Sublime merge build 1107 license mod#
- #Sublime merge build 1107 license license#
So, from what I've gathered so far, it seems to be an issue of SM trying to use the default/main Git account for all repositories (in my case, the GitHub account is the main account) and for some reason not being able to associate different accounts with different services.
#Sublime merge build 1107 license mod#
Right now I can't try this with SSH because of the above mentioned mod to the Git settings where I've manually added the user and password for each repository on my NAS drive - if you still need me to do that test I'll need to find a free time slot to unroll all those changes, but since the HTPPS test turned out to no longer ask for credentials I think that it might have answered already your question. I've tried the above steps with a Bitbucket repository via HTTPS, by launching SM from Git Bash, and I confirm it didn't ask me for credentials (not even on the first push). If you launch Sublime Merge from the terminal, do you see the prompt for the SSH passphrase every time? Tried it on Git's Bash, no output whatsoever.
git/config of each repository (because I use the MicroSoft credentials manager instead of Git's native, it seems I can't use some of the options that enable per-URL based credentials, as supported by Git's native manager).
#Sublime merge build 1107 license how to#
No idea how to fix that except by changing the. Somehow Git CLI is picking up the credentials on a per URL basis, but SM is not. This is not an ideal solution, but at least it restricts the problem. to define on each repository a new user, email and password in its Git configuration - because I noticed that SM was falling back to my standard account (GitHub), unlike Git CLI. As for the first test, I attempted with various keybindings but none showed any results in SM Git output panel (always says No previous commands history).Īs for the credentials in the Control Panel, I can see all the http credentials for GitHub, GitLab, Bitucket, etc, under Generic Credentials (of course, no reference to my NAS, since I use SSH only there).Īs for the NAS/SSH problem, I've found a workaround which seems to work, i.e. Not pleasant, at all, and was really hoping for a fix to the problem after two years. Either that or having to constantly switch to Bash for push and write operations. Sorry for the pessimistic tone of this last post, but try to stand in my shoes and imagine having to type a rather long and articulate password with every push operation, day by day, hundreds of times, while working locally on my private projects.
#Sublime merge build 1107 license license#
Is there an ETA for when this problem can be fixed? Two years is quite a long time for a bug that affects a core feature like credentials storage in an app that's dedicate to Git usage - and, to be honest, long enough to discourage license renewal when the time arrives. Having to enter the password for each push operation is really annoying. In my case, I'm facing the issue with a local GitBlit server installed in my Intranet, and connecting via SSH. The inability to cache credentials is a serious issue which jeopardizes the benefits of using SM for everyday work. I've found a Forum post that mentioned the menu option Tools > Passowrd Caching, but I can't see that menu in the current edition:
SM should ask for the password only once, and then store it somewhere. I can't understand why SM fails to see the Git credential files stored on my system (Win 10), while all other Git instances and front-ends pick them up correctly. May 2020, SM build 2011, and the problem persists (the Issue was opened 2 years ago).
0 kommentar(er)
