git integration?

[lukepighetti]

Just curious if there are any plans to offer a basic git integration

• change indicators in gutters
• diff comparisons
• stage, unstage
• stash, apply, pop
• change branch
• fetch, pull, push

[the-mikedavis]

Duplicate of #227

[the-mikedavis]

Diff signs in the gutter: #1623

Staging, committing, or any non-read-only operation on the git index is likely to live outside of Helix as a plugin.

[lukepighetti]

Is there any documentation on creating plugins?

[the-mikedavis]

The main issue for the plugin system: #122

It isn't implemented yet though, it's still in design / experimentation phase.

[lukepighetti]

Is there a roadmap/discussion that describes which features will be integrated, and which will be plugins? I do believe that a thoughtful git integration should be within the scope of included features, especially if helix is providing line gutters. IMHO there is very little missing from helix at the moment, and this appears to be the biggest one.

[the-mikedavis]

What belongs in core and what should live as a plugin tends to become a per-feature conversation. If you read through the open issues (especially those marked A-plugin) you'll see some of the opinions. There isn't a hard rule though so it would be tough to document.

With respect to git in particular, my opinion is that read-only operations on the index like diff gutters or a blame gutter are fine for core but anything that takes on write features like committing, stashing, pushing, etc. should live as a plugin. Git porcelain plugins like magit or even fugitive have huge scopes and deserve to be their own projects.

[pickfire]

Is there a roadmap/discussion that describes which features will be integrated, and which will be plugins? I do believe that a thoughtful git integration should be within the scope of included features, especially if helix is providing line gutters. IMHO there is very little missing from helix at the moment, and this appears to be the biggest one.

I didn't discussed this with the other maintainers but my own opinion is similar to what @the-mikedavis mentioned, something as generic and useful for the public like git on line gutters will probably be built-in, and something like git operations which users could have more opinion on is more likely to be on the plugin. Quite scary that the maintainers often have a similar opinion on what things should be in core and as plugin, maybe because we used quite a couple of editors and form an opinion on what should be the basic for built-in for modern editors?

[yvess]

I use lazygit if I want a bit more UI in a separate terminal window, goes nicely with helix editor

[jkbellew]

@yvess How do you use lazygit with helix if it's run in a different window?

[mattmc3]

@yvess How do you use lazygit with helix if it's run in a different window?

Usually, with tmux.

[nshern]

I use lazygit if I want a bit more UI in a separate terminal window, goes nicely with helix editor

But when you switch back to the helix window do you always need to :reload if you switched branch in LazyGit?

[quantonganh]

@alexandershern Here's the workaround to :reload-all automatically using WezTerm:

1. Create a custom event:

function basename(s)
  return string.gsub(s, '(.*[/\\])(.*)', '%2')
end

wezterm.on('reload-helix', function(window, pane)
  local top_process = basename(pane:get_foreground_process_name())
  if top_process == 'hx' then
    local bottom_pane = pane:tab():get_pane_direction('Down')
    if bottom_pane ~= nil then
      local bottom_process = basename(bottom_pane:get_foreground_process_name())
      if bottom_process == 'lazygit' then
        local action = wezterm.action.SendString(':reload-all\r\n')
        window:perform_action(action, pane);
      end
    end
  end
end)

2. Emit that event when switching back to the helix:

config.keys = {
  {
    key = '[',
    mods = 'CMD',
    action = act.Multiple {
      act.ActivatePaneDirection 'Up',
      act.EmitEvent 'reload-helix',
    }
  },