divmain/GitSavvy

Full git and GitHub integration with Sublime Text 3.

Charlie Allom

@yeled

you have to be in insert mode

I was projecting I think :)

Pavel Savchenko

@asfaltboy

Folks, I would love to help with release as people are raising old issues; anyone remember what is the protocol for the release? (did we document this somewhere and I missed it ?)

Randy Lai

@randy3k

I believe @kaste has some other bug fixes in place

There’s no documented protocol. I usually followed the gitflow approach to make a release branch and merge it into master.

Pavel Savchenko

@asfaltboy

Thanks to @stoivo the critical fixes and some features were merged! Hope we can do a release soon

Randy Lai

@randy3k

I spent some time today to review @kaste PRs. I think we should make a release once #1056 and #1061 are merged.

herr kaste

@kaste

divmain/GitSavvy#1048 should be solved. And of course https://github.com/divmain/GitSavvy/pull/1014#issuecomment-440016184 I'll take any fight here with this one :grinning:

So my take on #1014 is: We don't change anything here. This is the default, ih the user changed their git.config we take that for free because it is configured on the CLI and will apply automatically. If the user set a config in Sublime GitSavvy we will just take this value. We don't ask git config before every commit. That makes it lean. The behavior can be configured in many ways without any penalty. New, fresh users get a WYSIWYG commit message. Advanced users can set an option to their liking.

Randy Lai

@randy3k

I submitted the PR #1014 because I once committed accidentally some automatically generated comments t in COMMIT_EDITMSG

It is currently only relevent for prepare_commit_msg_hook

Randy Lai

@randy3k

we don’t check COMMIT_EDITMSG for other siutations

herr kaste

@kaste

That's a good solution. Only check and change 'cleanup_mode' if we prefilled the commit message. You're correct that this is only relevant for hook users, so only these users should get the feature.

Simon

@stoivo

I will start 2 use 2.18 branch

Pavel Savchenko

@asfaltboy

Last dev build looks interesting:
BUILD 3186 - 18 January 2019

Diffs are now shown in the gutter, showing the modified lines since the file was opened, or modified lines vs HEAD if the file is part of a Git repository. This can be disabled via the mini_diff setting.
Git: Various improvements to Git repository detection and handling
Git: Git status badges are shown in the Open Files section of the side bar
Git: Added support for includeIf in Git config files
Rewritten Lua syntax highlighting, with thanks to Thomas Smith
Various syntax highlighting improvements
Support for Unicode 11.0
Linux and Windows: Improved IME support
Linux: Fixed popup menu positioning on High DPI screens
Mac: Fixed middle mouse button support
Fixed a crash that could occur when nesting embed patterns in .sublime-syntax files
Minihtml: Fix hwb() to normalize w and b channels, and accept an alpha channel
Syntax Tests: Allow syntax test files to have a UTF-8 BOM
API: Added view.set_reference_document(), to control the mini diff target

Randy Lai

@randy3k

Ya, but it’s quite buggy, I have to revert to previous build

Adrian L Lange

@p3lim

when diffing a Lua file in-line in ST 3186 or newer, Lua syntax is not applied to the view

you can replicate this by creating a new dir, init git, add and commit the lua test file (link below), then add a change to that file and diff inline

https://raw.githubusercontent.com/Thom1729/Packages/50f282842c23339099f261cb7909a793a346eb8b/Lua/tests/syntax_test_lua.lua

not sure what's causing this, can only find this issue with Lua (which got its syntax updated in 3186)

Simon

@stoivo

Hmm

Kyle Bebak

@kylebebak

Hey all, a question

In divmain/GitSavvy@5f75d37 it seems like code was added that runs git commit before the git commit view is opened is there are pre commit hooks

This is a little weird, because these pre-commit hooks are running twice:
once before the git commit view is opened, and once when the commit actually takes place

Kyle Bebak

@kylebebak

I've tested this in multiple repos, using a hook I found in an old issue in GitSavvy

#!/bin/sh

sleep 1
echo "yo"
sleep 1
echo "hey"
sleep 1
echo "who loves slow commits?"
sleep 2
echo "this guy"
sleep 2

exit 0

One side effect of running actually running /usr/local/bin/git commit -q before opening the commit view is that if there's nothing to commit, the view simply doesn't open

Because this command exits with a status code of 1, not 0

This behavior does not occur if you don't have a pre-commit hook

You can open the commit view even if there's nothing to commit

So I guess those are the issues: we shouldn't run /usr/local/bin/git commit -q before opening the commit view, even if there is a pre commit hook. git commit and the pre commit hook should only be run when the user explicitly runs the commit from the commit view

Kyle Bebak

@kylebebak

If it makes sense to create an issue for this I'd be glad to

Randy Lai

@randy3k

We need to run the commit command before the view is opened. That is needed for the pre commit message hook at least, to obtain the message.

Kyle Bebak

@kylebebak

Rats, I figured there was a good reason it was running before opening the view =(

How about making it configurable via settings? Whether the command runs before opening the view?

Randy Lai

@randy3k

The issue of running the command only occurs when there is nothing to commit!?

if that's the case, we just need to catch the exception.

Kyle Bebak

@kylebebak

Yeah, I agree, but it won't solve the issue of having to run the pre commit hook twice, which is a bit painful for slow hooks, like the silly one I pasted above

But that's fine, I'm going to move slow stuff into pre-push instead of pre-commit

Randy Lai

@randy3k

It is unfortunately a side effect of perpare-commit-msg hook. AFAIK, there is no way to just invoke the perpare-commit-msg hook. Right now, the perpare-commit-msg hook and pre-commit hook are fired before the view is opened.

After the view the closed, we do the actual commit together with the commit-msg hook.

Unfornately, as the result of this, the hook pre-commit is triggered again.

There is a option to pass --no-verify in the second commit command, the pre-commit hook will not be triggered, however, it will also disable the commit-msg hook if there is any.

Kyle Bebak

@kylebebak

Ahh, cool, I'll look into passing --no-verify for the second command

Thanks for explaining, this definitely doesn't merit creating an issue

Simon

@stoivo

How do you run tests?

herr kaste

@kaste

You install 'UnitTesting' via PackageControl. Then invoke Test Current Package and more often Test Current File via command palette.

For Test Current File you must first be looking at a test file, after that you can walk around because it will remember the last file used.

dholland2377

@dholland2377

is anyone able to assist with a small setup problem I'm having?

dholland2377

@dholland2377

disregard, I skipped a step :(

Where communities thrive

People

Repo info

Activity