Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 07 2022 16:14
    kaste auto_merge_enabled #1631
  • Oct 07 2022 16:13
    kaste synchronize #1631
  • Oct 07 2022 16:13

    kaste on do-not-appveyor

    Remove testing on "appveyor" Add testing on Windows to the G… (compare)

  • Oct 07 2022 16:11

    kaste on rebind-tag-show-commit

    (compare)

  • Oct 07 2022 16:11

    kaste on master

    Re-bind `gs_tags_show_commit` t… Merge pull request #1630 from t… (compare)

  • Oct 07 2022 16:11
    kaste closed #1630
  • Oct 07 2022 16:09
    kaste opened #1631
  • Oct 07 2022 16:08

    kaste on do-not-appveyor

    Remove testing on "appveyor" Add testing on Windows to the G… (compare)

  • Oct 07 2022 16:05
    kaste synchronize #1630
  • Oct 07 2022 16:05

    kaste on rebind-tag-show-commit

    Re-bind `gs_tags_show_commit` t… (compare)

  • Oct 07 2022 16:05
    kaste closed #1629
  • Oct 07 2022 16:05

    kaste on master

    Fix: Move cursor to active bran… Rename `gs_branches_set_cursor`… Merge pull request #1629 from t… (compare)

  • Oct 07 2022 16:05

    kaste on hotfix-branch-navigate-to-active-branch

    (compare)

  • Oct 07 2022 16:05
    kaste auto_merge_enabled #1630
  • Oct 07 2022 16:04
    kaste opened #1630
  • Oct 07 2022 16:04

    kaste on rebind-tag-show-commit

    Re-bind `gs_tags_show_commit` t… (compare)

  • Oct 07 2022 16:02
    kaste auto_merge_enabled #1629
  • Oct 07 2022 16:02
    kaste opened #1629
  • Oct 07 2022 16:01

    kaste on hotfix-branch-navigate-to-active-branch

    Fix: Move cursor to active bran… Rename `gs_branches_set_cursor`… (compare)

  • Oct 06 2022 12:09
    kaste closed #377
Pavel Savchenko
@asfaltboy
Btw: I think #1031 may be causing duplicate output in the live panel on push
Randy Lai
@randy3k
Hi, @divmain we are still waiting for your reply on moving the project to a GitHub organization for better management. I believe it will allow us to better recruit collaborators.
Adrian L Lange
@p3lim
can we get those popup warnings displayed using a widget in ST instead of an OS alert box? OS alert boxes work very differently depending on the platform, would be nice to have something more uniform
it's a minor annoyance of mine since I develop on both windows and linux
Pavel Savchenko
@asfaltboy
It's an interesting idea, though I think the scope of such a PR might be large... Which sort of "popup warnings", like prompt dialogs? Do you want to replace all of them, or just some?
Adrian L Lange
@p3lim
popups with options such as the one you get when you push force, and yes
and yes, all of them :]
it might be more of an upstream request to ST itself, but I thought I'd toss the idea out there
Charlie Allom
@yeled
shame, that is one annoying UI action, closing the commit
Pavel Savchenko
@asfaltboy
@yeled can you elaborate what you mean about annoying UI when closing the commit?
Charlie Allom
@yeled
ah sorry, I've just re-erad the issue. I meant that when you close the commit in command mode (Six/Vintageous) it doesn't commit
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
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