poll: if you use Git, do you use a terminal text editor to edit your commit messages? (or other things that Git asks you to edit like interactive rebases etc)

(you can pick more than one)

@b0rk When in the terminal, which is most of the time, I use a terminal editor. But if I am in Emacs, I use Magit, the Emacs git frontend.

@b0rk _nearly_ got to tick all the boxes! I use emacs, but depending on the circumstances, it might be an emacs launched specially when I run 'git commit' from the shell prompt, or I may be running Magit in an emacs I had already. In either case the emacs may be GUI or tty-only, depending on whether I'm doing it at the other end of an ssh connection.

Alas, I couldn't think of any excuse to tick the 'other' box too :-)

(I do have a completely daft trick where I set VISUAL="cp file.txt", causing git to use the contents of that pre-prepared file instead of spawning an editor. But I only use that for prewritten 'git rebase -i' lists. For commit messages, there's no need: 'git commit' has a perfectly good -F option.)

@b0rk In “other”: I also use -m “…” from the command line if the message is simple enough

@simontatham @b0rk other: if it’s small, I’ll just do commit -m “Add one line for insert standard reason”

@b0rk I currently use gitui which is a TUI, which is perhaps not the same thing as a GUI? If I'm writing a longer commit message I'll open it in a terminal text editor, currently micro.

@b0rk I just use git commit -m and put the message in the terminal. Is that using a terminal editor?

@b0rk Commits and interactive rebases through vim because add-ons correctly wrap and highlight everything for me so i don't need to worry about line length or proper wrapping.

That said, the gitlens UI for interactive rebases in vscode is pretty good and I do use it whenever it decides to show it instead of popping my $EDITOR in the terminal pane, which is a coin toss for some reason.

@b0rk I also know the -m "message here" CLI syntax and very occasionally use it.

@b0rk Follow-up question would be "Terminal text editor: vim vs nano" 😂

@b0rk I clicked the GUI option as it's the closest, but I actually have GIT throw up an Emacs window, which is technically graphical but looks like a text interface.

@utterlymundane @b0rk oh, well, yes, for xkcd.com/1296 style commit messages that you're going to come back and write up more sensibly later, -m is good enough. I assumed those were out of scope for this poll!

I suppose a good example of "other" might be writing a description for a PR or MR on a git forge website, which is later turned into a commit message by some squash-and-merge workflow, discarding the messages from the actual commits you uploaded?

@b0rk Console editor for the most part, but I cobbled together a special flow for commits. It opens a tempfile in an editor and pops up a new terminal window running gittui. I can review edits in the latter while staging files, but still make notes in the former. When I quit the editor, the commit fires.

https://git.odin.cse.buffalo.edu/okennedy/random-hacks/src/branch/main/git-review

@drj @b0rk I use it very rarely, I never tell anyone about though as most people can't be trusted with it

@benofbrown @b0rk I've seen beginner guides use it (Djangogirls at one point), because it avoids having to get into the weeds about setting nano up, or worse, vi

@b0rk I use the Lazygit plugin in Neovim (which is kind of an IDE 🙂) in a terminal, so I don’t know which category that’s in 😅

@b0rk For some reason, I don't trust GUI tools to manipulate the git repository (probably because some GUI tool I've once tried to use made a mess of the repository state, turning a merge into a non-merge with the contents which should have been in the merge). So when editing files to resolve merge conflicts or when adding files and committing, I always use the trusty command line; which then defaults to the terminal text editor I have configured as default.

@b0rk Too lazy to change the default. I know vi well enough that it’s not a problem, plus I don’t want to switch out to a GUI text editor while I’m in the terminal.

@b0rk Either the terminal text editor or Lazygit.

@b0rk I create most of my git commits through the "fugitive" vim plugin. That keeps most of my commit messages inside my running vim session. Occasionally I'll do one in a command line, though, and that opens vim (my $EDITOR).

@b0rk I use lazygit. Guess that counts as "other".

@simontatham VISUAL=“cp file.txt” is incredible

@b0rk IMHO lazygit should have been an option

@b0rk most of the time i just write my commit message with -m but my .bashrc is configured with

if [[ "$TERM_PROGRAM" == "vscode" ]]; then
    export EDITOR='code --wait'
else
    export EDITOR='nano'
fi

so for when i need to write a longer one or i'm doing an interactive rebase or something, it depends on where i'm making the commit from

@simontatham @b0rk

That's horrible (complement).

(I'd be *way* too nervous to do that, and would just have the editor insert the prewritten text, though.)

@suetanvil @b0rk the usual reason I'm providing a prewritten 'git rebase -i' list in the first place is so I can try it over and over again until I get it right. For the same reason, I usually also make a separate clone of the git repo to do it in, so that I can mess up the first 10 attempts without doing any permanent damage!

@b0rk Random, depending on what exactly I'm doing, how extensive the commit message is going to be (they don't all need to be essays) and how I'm feeling.

@simontatham @b0rk

Ah, okay. That sounds perfectly reasonable and slightly disappointing.

@b0rk I use -m a lot, or lazygit's built in editor. I open nvim up for commits that need a lot of explaining.

@b0rk lazygit (TUI)

@b0rk sometimes I use gitui, a terminal based git interface.

@b0rk I use Lazygit for most things Git. It’s a beautiful program.

@b0rk Other: if I'm in the terminal (eg. ssh'd into a remote system) I'll try to use helix or vim if they're available to do commit messages. Otherwise I just commit directly in the IDE I'm using (Zed/VSCode).

@b0rk Additionally, if I have it installed, I'll use lazygit

@simontatham @suetanvil @b0rk When I'm going to do a rebase that I'm afraid I might mess up, I start with `git checkout -b rb`, and rebase that instead. Then when I'm happy with `rb` I reset the real ref to the same place. If I'm unhappy I delete `rb` and nobody is the wiser.

Why would you want to use a fresh repo?

@b0rk I voted other but maybe I'm 'terminal + magit'. For regular commits I basically always use Magit to make selective commits (so Magit + GNU Emacs and it's almost always as a GUI, not in a terminal). But when rebasing, if I hit a rebase conflict I fix it in the terminal and then 'git rebase --continue' usually throws me into vim to maybe fiddle with the old commit message.

@mjd @suetanvil @b0rk in more detail, the reason I've used this workflow in the past is when preparing a release branch of PuTTY, following on from a previous release branch but cherry-picking a subset of changes from more recent trunk development.

I go through and make a list of the trunk changes I think deserve to be on the release branch; cherry-pick them, test, make sure it all works; but that's a first draft, and then I consult with other team members to see if they have anything to add/remove or have opinions on the borderline cases. Then I maybe edit my list of cherry-picks and build a second-draft version of the release branch. That way the branch doesn't end up with "apply this change" / "revert it 2 weeks later" clutter.

The list of cherry-picks is nicest to keep in the form of a 'git rebase -i' todo list, rather than a plain shell script full of 'git cherry-pick' commands, because sometimes there's a conflict when cherry-picking a trunk change, and I prefer the rebase -i system of pausing, letting me fix it, and continuing.

So I fix the conflict, and in the next version of the todo file, I replace 'cherry-pick -x foo' with 'pick [new version of foo I just made]', so that the already-adapted version of that commit is the one that gets applied the next time I rebuild the draft release branch. Kind of like 'git rerere' except that I do it explicitly and state exactly _what_ saved conflict resolution I want to use, and when.

The part about picking commits from an earlier draft branch depends on those commits not having been garbage-collected since I last ran the script. So I do all of this in a separate clone of the repo from the one where I'm doing unrelated trunk development.

Also, the full branch rebuilding script includes commands to switch branch, delete branch, recreate branch etc. Another reason to keep it far away from unrelated work.

@simontatham @b0rk I have sometimes done GIT_EDITOR=cat for rebases, when I just want an automatic fixup. (Less necessary now, as git is getting more tools for this.)

@simontatham @mjd @suetanvil @b0rk do you version your rebase files? no need to answer

this is amazing but also terrifying

@b0rk
Even when I use a GUI text editor for the actual edit, I typically use vim or nano for the commit message.

@simontatham @utterlymundane @b0rk it doesn't have to be too sinful, if you commit a lot on a branch and squash before or during merge.
Can end up like neat bullet points. In theory.

@b0rk Does git commit -m "Line 1" -m "Line 2" ... count?

@b0rk I usually use a terminal text editor and magit (an "IDE editor" in this poll), but because I also do almost all of my work in a terminal effectively _all_ my editor use falls into that same category. (And emacs in a terminal running magit, so... an IDE but still not really a GUI?)

@gnomon Now I'm thinking about where I'd draw the line for Emacs as editor versus IDE. When you run M-x shell (or M-x compile or etc) so you can build and test your program without leaving Emacs?

@b0rk oh no, crap. I voted for the wrong thing. I use a TUI - lazygit. Which... is in a terminal. And has a built in text editor (for editing commit messages, etc). But, it's not (strictly speaking) A Terminal Text Editor.

Sorry about that.

@cks Yeah, the dividing line definitely gets murky.