I was annoyed by a lack of support for git worktrees in my current employer's dependency system (think virtualenv from python, but for everything). I fixed some scripts to be worktree dependent and tested it out thoroughly on the CLI, but as soon as I got the PR through with the change, I got a bazillion messages on Teams from people yelling at me that I broke their workflow.

Their workflow was basically "blindly point and click in Visual Studio because I don't understand even the basics of git. I miss the old custom in-house VCS and am very grumpy".

You're confusing "git" (which is relatively easy to understand and use) with "the git CLI" (which is a UX nightmare).

I learnt how to use git years before I learnt to use the git CLI.

You forgot the people that only know: git commit -a -m "foobar" and think that's better than using a GUI to easily make clean commits.

If I could enforce one thing, it would be to REQUIRE partial commits for everything from an UI. I can't tell you the amount of commits I have seen that need to be cleaned up from spare debugging statements to vendor files to things that need to be added into the git ignore.

The other thing would be to make sure people understand what things like 'squash' and 'rebase' to and how they effect the tree.

Also to explain if you have multiple features, please don't work on it all on the same branch unless you have too. (This is a internal workflow, not really related to git but how we handle merges)...

Yeah, a UI could be just fine for an experienced git user. In my experience though, experienced git users don't use it though, so it's a moot point.

> from an UI

Just a really quick aside...

Do you... say "oooey" instead of "you eye" when reading "UI"?

UI