VCS/git support

[kirawi]

As a plugin for git to begin with.

Prior Art:

• fugitive.vim
• emacs

[pickfire]

magit is interesting but it hides a lot of useful feature.

[ahkrr]

I am usingt gitui About: Blazing fast terminal-ui for git written in rust
Maybe some components could be reused, or maybe gitui could be called or integrated somehow?
One can already open and edit files with VISUAL=hx EDITOR=hx gitui from gitui.

[gbaranski]

There is also nice Neovim plugin which shows what have been changed in the source tree, https://github.com/lewis6991/gitsigns.nvim
It's similar to what vscode has.

[heliostatic]

Ah, yes, I searched git and missed this issue. Thanks @kirawi.

I'll add votes for:

• gutter indicators
• something with https://github.com/extrawurst/gitui/

[kirawi]

I just renamed it, so no worries :P

[QiBaobin]

One great thing is that we could reuse all our editor knowledge when providing a fugitive or magit feature, like searching, diff etc. Using another tool is a total different experience.

[poliorcetics]

Being able to use hx as a difftool in git (and maybe other VCS, I don't know if they have the option) would be very nice !

[heliostatic]

Just adding links to the git gutter symbols PR and the file comparison issue:

• Show git diff signs in gutter #1623
• Side by side file diffing #405

[the-mikedavis]

I think much of the fugitive/magit/lazygit/gitui functionality belongs outside the core as plugin(s) but I think some read-only VCS information could belong in the core. In particular diff signs (whether VCS based or not - already being implemented) but also I think it isn't a stretch to have a gutter in the core for git's blame information.

[theherk]

I can see the vcs implementation living in a plugin, but I think magit in unparalleled. It is much more discoverable than some may realize. Fugitive is great but magit with the blame, time machine, and difftool integration in magit is the thing that will keep me using emacs for the foreseeable future.

I'd love to work on such a plugin.

[Yevgnen]

The way how magit works with transient.el is great.

[theherk]

Just following up with a bit of supporting data from /r/emacs. I thought it was worth noting just how high the proportion is of people who consider magit a core part of their emacs life.

It is for this reason, that I have come to believe no matter the outcome of the plugin-system-or-not conversation ongoing in #122, tight and powerful git integration should be part of the core distribution of helix. Maybe @extrawurst, the creator of gitui would be interested in joining such a cause.

[babakabdolahi]

Just following up with a bit of supporting data from /r/emacs. I thought it was worth noting just how high the proportion is of people who consider magit a core part of their emacs life.

It is for this reason, that I have come to believe no matter the outcome of the plugin-system-or-not conversation ongoing in #122, tight and powerful git integration should be part of the core distribution of helix. Maybe @extrawurst, the creator of gitui would be interested in joining such a cause.

I also think git integration is also as fundamental as LSP, grep and fuzzy finder and should be part of the core distribution of helix.

[wojpawlik]

The simplest and most unixy way to go would be to add a keybind that saves all files and launches https://github.com/extrawurst/gitui

[theherk]

Maybe that would be the most simple to implement, but I'm not convinced it would be the most simple to use, which is also important. I think there is some benefit to unifying the experience, so the interface and behavior are consistent.

In addition, the time machine and blame interfaces within the editor is really a nice quality of life tool, that just wouldn't work if the git tool were completely isolated from the editor.

[theherk]

Also, I saw that @extrawurst just starred helix, so maybe they'll want to get involved or offer some suggestions on how tightly they could / should be coupled. 🤞

[univerz]

+ diffs with editor-quality syntax highlighting and the ability to do final cleanups / small fixes right in the side-by-side diff are solid productivity boosts.

[cd-a]

I really want to try helix but not having first class git integration is the one and only blocker for me.

Since it already implements LSP it should be clear it's aimed at source code editing, and therefore I'd rather have core support than plug-in support.

[vkoskiv]

My Rust is sadly far too weak to take a stab at this myself, but the ability to hit something like <space>-b to show a git blame for the current line, and/or multiple lines in a selection would be just excellent. I think it would be a great fit for Helix, and perhaps a somewhat modest starting point for broader Git integration in the future.

[gobijan]

This is the best keyboard based Git integration for an editor (Sublime) I came across.
Could be a nice inspiration.

https://github.com/timbrel/GitSavvy

[quantonganh]

but the ability to hit something like -b to show a git blame for the current line, and/or multiple lines in a selection would be just excellent.

@vkoskiv If you are using WezTerm, the current file name and line number can be parsed from the status line by using something like this:

status_line=$(wezterm cli get-text | rg -e "(?:NORMAL|INSERT|SELECT)\s+[\x{2800}-\x{28FF}]*\s+(\S*)\s[^│]* (\d+):*.*" -o --replace '$1 $2')
filename=$(echo $status_line | awk '{ print $1}')
line_number=$(echo $status_line | awk '{ print $2}')

then it can be passed to tig:

case "$1" in
  "blame")
    split_pane_down
    echo "tig blame $filename +$line_number" | $send_to_wezterm_pane
    ;;

split_pane_down() {
  pane_id=$(wezterm cli get-pane-direction down)
  if [ -z "${pane_id}" ]; then
    pane_id=$(wezterm cli split-pane)
  fi

  wezterm cli activate-pane-direction --pane-id $pane_id down

  send_to_wezterm_pane="wezterm cli send-text --pane-id $pane_id --no-paste"
}

and finally, you can create a new minor mode bound to ;:

[keys.normal.";"]
b = ":sh hx-wezterm.sh blame"

[dlants]

I agree that version control is something that's really fundamental, and based on the approach of helix so far seems like it belongs in the core.

I also think it would be better to integrate it into helix itself in situations where you want to select, yank or edit text. (rather than delegating to something like gitui). So things like browsing diffs, blame, looking at previous versions of files, etc...

The rest of the stuff (staging, commits, remotes, git log) is maybe less important to do inside the editor itself, and could be delegated to a plugin or a separate tool?

I really enjoy using fugitive, but I do think that it's not quite helix-y from the point of view of discoverability. I've been using it for like 20 years and I still only use a really small subset of what I know it's capable of, since I forget how to activate the fancier features and never bother to look them up, resorting to the git cli or web UI instead.

[ds-281]

Just adding myself to the list of people interested in this issue. The one killer feature I'm really missing from vim-fugitive is the reblame function of :Git blame (navigating on a specific line and pressing ~ reloads the file as in that commit's tree and reloads the blame) and the possibility to load the selected commit in a dedicated pane (with o).

This is really the only thing missing in my workflow that prevents me from fully leaving vim behind.

[dmitry-krasilnikov]

I am willing to work on git blame feature starting with a simple "blame this line and show it in a popup" and then improving on that, e.g. full blame of a file, re-blame. I already have "git blame line" implemented as a command in my fork of a helix and it works well. It's far from being ready as a PR, the architecture is not right, and there are no tests, but I can re-write it and open a PR if it's welcome.

[jpaju]

If I've understood correctly, the problem is that Helix uses gix for git integration and gix (to my knowledge) doesn't have git blame implemented yet

[extrawurst]

@jpaju you are right it currently does not support blame but there is some convo around implementing it, let’s make sure to not duplicate efforts here. You can find more context here: GitoxideLabs/gitoxide#1078 (comment)