Hacker News Reader

Comment by neves | Hacker News Reader

I'm a somewhat advanced user of Git. My coworkers use me as a reference when they have a problem of a difficult merge to solve.

I don't follow each Git release, but I also didn't notice a great productivity enhancement for a long time. Sure it is a sign of a mature project, but I'd like to know:

What's the somewhat recent Git feature that you really improved your productivity?

View on HN

For the past few years the performance work (e.g. commit graph) has made a huge difference for large/fast moving repos. They're big enough to be productivity enhancements for some people: when we merged our Android-like multi-repo setup into a proper mono-repo we required updating git because things like git status/git commit/git log could take minutes without the recent perf fixes.

It pays to follow the release notes because some of these features are opt-in (e.g. commit graph is still optional).

The sparse checkout stuff is great but still too low-level for us to use, but it's laying the groundwork for something good.

  git range-diff

Very useful to get an overview of what changed after a rebase.

https://git-scm.com/docs/git-range-diff

Thank you for mentioning this. I wrote my own bash script to do something similar ages ago, but I'm betting this will be much less janky.

Really nice. I hope GitHub use this option soon.

Or maybe not: I guess it's kinda slow and heavy on computation.

As someone doing lots of merges in a big and active project, git rerere has saved me hours whenever I need to redo a complicated merge.

It's not at all new according to a quick grep of RelNotes, but I only recently discovered it, so it is new to me.

Conversely, I hit that years ago (long-running migration tarpit) and forgot about it until I setup a clean home directory on a system which didn’t have my dotfiles repo and thought I’d hit a major Git regression. It saves you time on exactly where you need it the most.

git diff --color-moved

This makes git diff highlight reindented or moved lines differently.

I use it to get diffs similar to when you pass -w, but with a bit more context.

It takes a bit of experimenting to keep it from looking like a fruit salad, but sometimes you get interesting results.

https://git-scm.com/docs/git-diff#Documentation/git-diff.txt...

If you use git diffs frequently, I recommend setting up delta: https://github.com/dandavison/delta

And I am working on implementing color-moved support https://github.com/dandavison/delta/issues/72

git worktree.

Godsend if you regularly need to work on multiple branches simultaneously.

What does worktree provide that a fresh local clone doesn't?

Reduced disk space usage for large repositories. And a convenient way to manage all your clones

I guess it reduces duplicating the history? Large files are by far the bulk of what I personally deal with so it don't think there's a real difference for me but I could see it helping.

Yeah, it only stores the objects in the .git directory once.

If it's a multi-gigabyte repo that you are cloning over a slow VPN, it speeds things up quite a bit.

The `--reference` and `--dissociate` flags to `git clone` can be used to avoid the majority of the network transfer while still creating an independent local repository.

Like I said, I'd usually just clone locally, as in clone from the repo you already have on disk.

Maybe too obvious, but if you’re not pushing everything to the remote, local-only content is available in both worktrees.

“Let me share the Good News of git worktrees” is a thing I say often in our work Slack.

git switch/git switch -c so much better than git checkout and the confusing switches.

Not for me.

Those confusing switches are already ingrained in my memory (or hidden away behind aliases) and now I find it more confusing that git is recommending new and different commands to do things that I've been doing a fixed way for years.

`git restore <file>` instead of `git checkout -- <file>`is another one.

Well, I guess the good thing here is that they're not going to remove the old checkout behaviour. And these new commands are much easier to use and understand for a beginner.

well git checkout basically is confusing because it does two things at once.

git restore and git switch basically tries to seperate the functionality.

i.e. from: "git-checkout - Switch branches or restore working tree files"

- "git-switch - Switch branches"

- "git-restore - Restore working tree files"

tbf I found it really stupid from the beginning that it tries two things at once.

Setting up watchman as a Git hook for fsmonitor.

It speeds up git status on large codebases

https://github.com/git/git/blob/master/templates/hooks--fsmo...

Sparkle/partial checkout for big repo or legacy or people doing shit with git

git restore

+1 this.

It's not just better name for doing "git checkout -- path". "git checkout" has this stupid behavior of restoring files to worktree and index. "git restore" by default doesn't touch index (I wrote SO answer that explains this a bit more: https://stackoverflow.com/a/60855504/350384)

there is also "git switch" but I just kept using "git checkout" because there is nothing "git switch" can do that "git checkout" can (it's just a shorter name but I had aliased "checkout" to "ch" anyway, as many people do)

Reply on news.ycombinator.com