4 ms·

I can't tell if this is engaging with trolls or not, but I can't imagine that all of your interactions with your codebase are via `git log` with no other flags.

I can't tell if this is engaging with trolls or not, but I can't imagine that all of your interactions with your codebase are via `git log` with no other flags. Even the with the normal Git CLI that most of us use daily, most of us use `--oneline` or whatever to simplify useful calculations and visualizations like `--graph`, etc. But we're talking here mostly about code archeology, learning about the history of a block of code, so this comment seems somewhat ridiculous in that context.

bee_rider 3y ago
Is it possible that you’ve been hit by https://xkcd.com/2501/ https://xkcd.com/2501/ ? git log | less /whatever Works OK for those of us who don’t know any git flags.
- account42 3y ago
  Why an explicit `| less`? Git already uses a pager by default.
- fl0ki 3y ago
  The only sets of arguments I use to git log regularly: * `git log branch` because I want to cherrypick or checkout parts of another branch. * `git log --stat` because what files changed can be a big clue for what I'm looking for. * `git log -- dir1/ file1/` because I only care about commits to a certain part of the tree. Other than that, `git log` already provides so much information to /search or even `grep` through that I can't think of any other flags I use regularly, and if you don't use them regularly you forget them. The real GOAT that people are sleeping on is `git rebase --interactive` where you can go back and edit part of your branch to clean it up before rebasing or merging towards main. The cleaner the commits are, the more useful they become later for other tools like log, merge, rebase, cherry-pick, bisect, etc.
  - ycombobreaker 3y ago
    A rebase to clean up your branch is great, and I lean on my team to do this. Unfortunately it's impossible to automate, because it amounts to craftsmanship. I've seen larger teams fall back to squash-merging, which at least discards checkpoint/broken/WIP commits. But it loses the nuance of more complex changes performed in logical stages.
- mb7733 3y ago
  I don't know how my comment was understood to mean that I am unfamiliar with git. My point was that those of us that use the git CLI have no issues seeing the rest of a commit message besides the first line, and in fact this is the default.
mb7733 3y ago
> I can't imagine that all of your interactions with your codebase are via `git log` with no other flags. When did I say anything like that? My point is just that the `git log` command, by default, shows the full commit message. The same goes for `git show`. So a user of the git CLI will regularly see complete commit messages, unless they purposefully request a different format. So, it is not some inherit problem in git that the complete commit message is hard to find. That's just a limitation of certain Git frontends.
keybored 3y ago
> I can't tell if this is engaging with trolls or not, […] that most of us use daily, most of us use `--oneline` You speculate that someone who uses git log without listing (or complaining about) all their flags are a troll?

bee_rider 3y ago

Is it possible that you’ve been hit by https://xkcd.com/2501/ https://xkcd.com/2501/ ? git log | less /whatever Works OK for those of us who don’t know any git flags.

account42 3y ago
Why an explicit `| less`? Git already uses a pager by default.
fl0ki 3y ago
The only sets of arguments I use to git log regularly: * `git log branch` because I want to cherrypick or checkout parts of another branch. * `git log --stat` because what files changed can be a big clue for what I'm looking for. * `git log -- dir1/ file1/` because I only care about commits to a certain part of the tree. Other than that, `git log` already provides so much information to /search or even `grep` through that I can't think of any other flags I use regularly, and if you don't use them regularly you forget them. The real GOAT that people are sleeping on is `git rebase --interactive` where you can go back and edit part of your branch to clean it up before rebasing or merging towards main. The cleaner the commits are, the more useful they become later for other tools like log, merge, rebase, cherry-pick, bisect, etc.
- ycombobreaker 3y ago
  A rebase to clean up your branch is great, and I lean on my team to do this. Unfortunately it's impossible to automate, because it amounts to craftsmanship. I've seen larger teams fall back to squash-merging, which at least discards checkpoint/broken/WIP commits. But it loses the nuance of more complex changes performed in logical stages.
mb7733 3y ago
I don't know how my comment was understood to mean that I am unfamiliar with git. My point was that those of us that use the git CLI have no issues seeing the rest of a commit message besides the first line, and in fact this is the default.

mb7733 3y ago

> I can't imagine that all of your interactions with your codebase are via `git log` with no other flags. When did I say anything like that? My point is just that the `git log` command, by default, shows the full commit message. The same goes for `git show`. So a user of the git CLI will regularly see complete commit messages, unless they purposefully request a different format. So, it is not some inherit problem in git that the complete commit message is hard to find. That's just a limitation of certain Git frontends.

keybored 3y ago

> I can't tell if this is engaging with trolls or not, […] that most of us use daily, most of us use `--oneline` You speculate that someone who uses git log without listing (or complaining about) all their flags are a troll?