16 ms·

My git productivity hack is `git diff --color-words`. Instead of showing the line-by-line diff, it shows only the words that changed. Especially useful if you h

by hkopp 5y ago

My git productivity hack is `git diff --color-words`. Instead of showing the line-by-line diff, it shows only the words that changed. Especially useful if you have long sentences where only a comma changed or some other typo. With git diff, the two lines are shown, with --color-words, only the changed symbol is highlighted. The option --color-words also works with git show. I even made aliases for them: git cshow and git cdiff. Other than that, I recommend that people learn to use git properly. In my work, I often have problems with people overwriting their commits and trying to handle merge requests of commits where one commit message is "did some updates" and the other commit is "some fixes". Getting to know git for an hour, may have prevented both issues. But I am biased, since I use git since my bachelor thesis.

mtekman 5y ago
In a similar manner for Emacs users: magit-toggle-refine-hunk is a lifesaver for word diffs
- andreareina 5y ago
  Key combo `D t`
leephillips 5y ago
Thanks for teaching me about --color-words. I didn’t know about it, and I greatly prefer it over the normal git diff output.
lisper 5y ago
> Other than that, I recommend that people learn to use git properly. Sorry to be harsh here, but that is completely useless advice. It's a tautology. Of course people should learn to use git "properly". What's the alternative, that they should learn to use it improperly? Everyone should learn to use everything properly. It's like telling someone dealing with a crisis that they should "take appropriate action", as if taking inappropriate action was something that someone would actually seriously consider absent this advice. The problem is that no one knows what "properly" means when it comes to git. Git itself provides no clue, and everyone and their second cousin has an opinion. That makes the advice to use git "properly" utterly vacuous. Figuring out what "properly" means is the whole problem with git. [UPDATE] See also my earlier comment here: https://news.ycombinator.com/item?id=27580478 https://news.ycombinator.com/item?id=27580478
- yjftsjthsd-h 5y ago
  > What's the alternative, that they should learn to use it improperly? Yes. Or at least, avoid learning anything if they can help it, treating it as a black box that can never be understood. "Learn got properly" just means "actually make an effort to learn the tool rather that clinging to learned helplessness".
  - lisper 5y ago
    See my earlier comment here: https://news.ycombinator.com/item?id=27580478 https://news.ycombinator.com/item?id=27580478
  - TameAntelope 5y ago
    A viable alternative my coworkers seem to have adopted is, “Execute the git commands blindly as provided by me and get upset with git when something doesn’t work right.”
- richrichardsson 5y ago
  > What's the alternative Perfectly explained here : https://xkcd.com/1597/ https://xkcd.com/1597/
- Shacklz 5y ago
  > Figuring out what "properly" means is the whole problem with git. I think you've missed OPs point by focusing too much on a single word ('properly'). Yes, there's no clear-cut way on how to use git, no silver bullet, but the main problem with git is that most devs simply panic when they have to do anything that goes beyond the bog-standard commit/pull/push/merge. Rebase? Squash? Reset? Rebase interactively? I think OP was referring to this cluelessness with 'not using properly', rather than which approach to git is the best. I work on a monorepo with 40-something other devs, and we've recently switched to enforced linear history because the history got to the point of being completely useless, it was an unreadable spiderweb. The problem was not that folks didn't see that what they were doing was not-so-good (introducing often more merge-commits with every PR than non-merges), it was that they had no clue how to avoid that. It took us quite a bit of time to get everyone up to speed but pretty much everyone got around to it after a while. It's not rocket science after all.
imiric 5y ago
I highly suggest delta[1] for viewing diffs on the command line. It pretty much replicates GitHub's diff rendering, and is quite configurable. [1]: https://github.com/dandavison/delta https://github.com/dandavison/delta
- kevincox 5y ago
  I am very happy with delta. I slightly tweaked the default config and it is great. [core] pager = delta [interactive] diffFilter = delta --color-only [delta] features = navigate hunk-header-style = omit line-numbers = true line-numbers-left-format = "{nm:>3} " line-numbers-right-format = "{np:>3} " max-line-length = 0
- Liskni_si 5y ago
  There's also diff-highlight[1] which is shipped with git itself and does almost the same thing, just possibly isn't as polished. [1]: https://github.com/git/git/tree/master/contrib/diff-highlight https://github.com/git/git/tree/master/contrib/diff-highligh...
- manexploitsman 5y ago
  Tig - Text-mode interface for Git with basic vim bindings https://jonas.github.io/tig/ https://jonas.github.io/tig/
cush 5y ago
> properly Or maybe just don't shame people for not working the way you do.
- CRConrad 5y ago
  If one guy says "This shit doesn't work!" and the other says "This is how it works", then it seems more like knowing how it works, well, properly than "shaming".
NilsIRL 5y ago
I also like to use `git diff --color-words=.` to do a character wise diff instead.
levzettelin 5y ago
Looking at diffs on the command-line is cute and all, but for anything substantial I doubt this will ever be as good as using a proper GUI interface. I like "meld". You have to install it, then run git config --global alias.meld '!git difftool -t meld --dir-diff' and after that you can do: git meld # like "git diff" git meld --staged # like "git diff --staged" git meld branchA branchB # like "git diff branchA branchB"
- mixmastamyk 5y ago
  It's good as the mergetool but overkill for a simple diff.

by hkopp 5y ago

mtekman 5y ago

In a similar manner for Emacs users: magit-toggle-refine-hunk is a lifesaver for word diffs

andreareina 5y ago
Key combo `D t`

leephillips 5y ago

Thanks for teaching me about --color-words. I didn’t know about it, and I greatly prefer it over the normal git diff output.

lisper 5y ago

> Other than that, I recommend that people learn to use git properly. Sorry to be harsh here, but that is completely useless advice. It's a tautology. Of course people should learn to use git "properly". What's the alternative, that they should learn to use it improperly? Everyone should learn to use everything properly. It's like telling someone dealing with a crisis that they should "take appropriate action", as if taking inappropriate action was something that someone would actually seriously consider absent this advice. The problem is that no one knows what "properly" means when it comes to git. Git itself provides no clue, and everyone and their second cousin has an opinion. That makes the advice to use git "properly" utterly vacuous. Figuring out what "properly" means is the whole problem with git. [UPDATE] See also my earlier comment here: https://news.ycombinator.com/item?id=27580478 https://news.ycombinator.com/item?id=27580478

yjftsjthsd-h 5y ago
> What's the alternative, that they should learn to use it improperly? Yes. Or at least, avoid learning anything if they can help it, treating it as a black box that can never be understood. "Learn got properly" just means "actually make an effort to learn the tool rather that clinging to learned helplessness".
- lisper 5y ago
  See my earlier comment here: https://news.ycombinator.com/item?id=27580478 https://news.ycombinator.com/item?id=27580478
- TameAntelope 5y ago
  A viable alternative my coworkers seem to have adopted is, “Execute the git commands blindly as provided by me and get upset with git when something doesn’t work right.”
richrichardsson 5y ago
> What's the alternative Perfectly explained here : https://xkcd.com/1597/ https://xkcd.com/1597/
Shacklz 5y ago
> Figuring out what "properly" means is the whole problem with git. I think you've missed OPs point by focusing too much on a single word ('properly'). Yes, there's no clear-cut way on how to use git, no silver bullet, but the main problem with git is that most devs simply panic when they have to do anything that goes beyond the bog-standard commit/pull/push/merge. Rebase? Squash? Reset? Rebase interactively? I think OP was referring to this cluelessness with 'not using properly', rather than which approach to git is the best. I work on a monorepo with 40-something other devs, and we've recently switched to enforced linear history because the history got to the point of being completely useless, it was an unreadable spiderweb. The problem was not that folks didn't see that what they were doing was not-so-good (introducing often more merge-commits with every PR than non-merges), it was that they had no clue how to avoid that. It took us quite a bit of time to get everyone up to speed but pretty much everyone got around to it after a while. It's not rocket science after all.

imiric 5y ago

I highly suggest delta[1] for viewing diffs on the command line. It pretty much replicates GitHub's diff rendering, and is quite configurable. [1]: https://github.com/dandavison/delta https://github.com/dandavison/delta

kevincox 5y ago
I am very happy with delta. I slightly tweaked the default config and it is great. [core] pager = delta [interactive] diffFilter = delta --color-only [delta] features = navigate hunk-header-style = omit line-numbers = true line-numbers-left-format = "{nm:>3} " line-numbers-right-format = "{np:>3} " max-line-length = 0
Liskni_si 5y ago
There's also diff-highlight[1] which is shipped with git itself and does almost the same thing, just possibly isn't as polished. [1]: https://github.com/git/git/tree/master/contrib/diff-highlight https://github.com/git/git/tree/master/contrib/diff-highligh...
manexploitsman 5y ago
Tig - Text-mode interface for Git with basic vim bindings https://jonas.github.io/tig/ https://jonas.github.io/tig/

cush 5y ago

> properly Or maybe just don't shame people for not working the way you do.

CRConrad 5y ago
If one guy says "This shit doesn't work!" and the other says "This is how it works", then it seems more like knowing how it works, well, properly than "shaming".

NilsIRL 5y ago

I also like to use `git diff --color-words=.` to do a character wise diff instead.

levzettelin 5y ago

Looking at diffs on the command-line is cute and all, but for anything substantial I doubt this will ever be as good as using a proper GUI interface. I like "meld". You have to install it, then run git config --global alias.meld '!git difftool -t meld --dir-diff' and after that you can do: git meld # like "git diff" git meld --staged # like "git diff --staged" git meld branchA branchB # like "git diff branchA branchB"

mixmastamyk 5y ago
It's good as the mergetool but overkill for a simple diff.