4 ms·

Why do people think that having branches in their history is "unclean"? I'm struggling to understand what is the issue here.

yakkityyak 4y ago
I'm betting that a perfectly linear git history is probably easier/nicer to have for people who think of git as a sequence of deltas. That is not how git works, but I can understand the appeal. For all my personal projects I squash and merge everything.
- teraflop 4y ago
  If you have a Git repository with merge commits that merge changes back into your main branch, all you have to do is "git log --first-parent -m" to get a log that looks exactly as if you had squashed and rebased every change. I'm surprised I don't see more people talking about this option. Sure, the syntax is inelegant, but it seems like it gives you the best of both worlds: you can browse your history as if it was linear, and drill down to the individual commits in a branch only when necessary.
  - tsimionescu 4y ago
    Do Github, GitLab, BitBucket, or any other Git UIs support this option? Relatively few people use the command line for inspecting Git history. Not even sure Magit exposes this option directly in most places where it shows history, I believe.
    - zdw 4y ago
      Gerrit has a way to look at all patches uploaded, but only take the last one which should be squashed/rebased, if it's configured that way (The "Fast forward only" option). It results in very clean history, and unmodified commit hashes from a developer's commit, whereas Github's Squash and Merge will mangle the commit message by adding a PR # to it, as well as other comments, which changes the hash. PR #'s are not as good as clean hashes, IMO. As someone who went from an org that was using Gerrit to mandatory Github usage, the latter is definitely a step backwards in code review. That said Github does have a better browsing interface than gitiles.
    - graton 4y ago
      > Relatively few people use the command line for inspecting Git history. Counterpoint: I use the command line all the time to look at Git history.
      - seba_dos1 4y ago
        Same here. Web UIs are pretty cumbersome compared to Git and only really useful for quick lookups in recent history. For anything else, git log is much more convenient.
  - graton 4y ago
    > all you have to do is "git log --first-parent -m" What is the `-m` for? Looking at the man page it says: "-m will produce the output only if -p is given as well." Did you mean "--max-parents=1" as a different commenter used with "--first-parent"?
    - seba_dos1 4y ago
      You rarely want to use `--max-parents=1` with `--first-parent` as that will hide all merge commits and merged branches entirely. `-m` is useless here, just use `git log --first-parent`.
    - teraflop 4y ago
      The "-m" doesn't do anything by itself, but it's there in case you want to add an option like "-p", which otherwise wouldn't show a useful diff for a merge commit. With "--first-parent -m -p", the log shows only the diff of the merge commit against its first parent, which is the same as what you would get from squashing.
- tsimionescu 4y ago
  This depends less on how you conceive of Git, and more on the project's development model. For example, in a team using Git for an internal product, with a centralized repo a main branch and (relatively short-lived) feature branches, the conceptual history of the repo is linear. Seeing all of the merges that everyone did when getting into work is line noise, not likely to be meaningful - so rebasing feature beanches on master every day and then doing squash or FF commits when merging back into master makes the most sense. Alternatively, for an open source project with no "blessed", and with long-lived branches that get contributed by various orgs, trying to make the history appear linear would help nobody. So obviously this kind of model wouldn't work for Linux, but it works better for most in-house software using Git as a centralized VCS with some nice offline history features.
kortex 4y ago
Because it is visual noise. It's really hard to track, especially on the CLI. It's also a lot easier to reason about the codebase through time if it's basically a linear track. We started off with merge commits and moved to squash rebase (team history to team clean), and I gotta say, I absolutely love team clean in the overwhelming majority of cases. The only time team history is handy is as a sort of temporary space on feature branches where you are sorting out complex merges, debugging, or trying different patterns. But all of that gets squashed away onto main eventually.
- ilammy 4y ago
  > It's really hard to track, especially on the CLI. git log --first-parent --max-parents=1 Now you don't see merge commits. Forbid merge commits with conflict resolution, and you're done.
  - Gigachad 4y ago
    How do you forbid the ones with resolution? Genuine question because it seems like merge commits are a black hole where anything could happen and no one would notice.
    - seba_dos1 4y ago
      Just require the merged branch to be fast-forwardable (but don't actually fast-forward it). If it's not, it will be obviously visible in `git log --graph`.
  - seba_dos1 4y ago
    You usually don't want to use both arguments at the same time as that will hide the whole merges (both merge commits and merged commits). You can however use one of those arguments to choose what you want to filter out, which is very handy. FWIW, `--max-parents=1` has an alias `--no-merges`.
- raggi 4y ago
  git log --topo-order
generationP 4y ago
When merge commits involve conflict cleanup, they are very hard to debug (at least with standard tools like tig/gitk/diff; there might be something more advanced). I've seen lines of code disappear into nowhere in merge commits. You can only hope the conflicts were resolved well. Even conflict-free merges can be scary -- you're trusting the system to find the right context. Of course, the same errors can happen on rebase, but at least the resulting commits can easily be inspected.
- georgyo 4y ago
  The problems here come from the fact that a "merge" commit is just a normal commit with multiple parents. This means that anything can happen inside that merge commit, including add, remove, and modify all the code, even if not touched by a parent. Merge commits are good place for a malicious actor to hide changes.
dataflow 4y ago
Do you have a useful & understandable mental model for "delta"-based operations like "rebase", "revert", etc. for arbitrary commit DAGs? Admittedly I haven't sat down to think about it for very long, but I feel like I'm not the only one who feels like lots of operations (including those) become difficult if not impossible to reason about with nonlinear history.
gregmac 4y ago
I can see it being an issue with people that don't bother to keep clean git history? Eg, that write commit messages like "fixed bug" "oops" "more stuff". I'm on Team Write-Good-Commit-Messages. The key of being on this team is learning interactive rebase: of course everyone makes mistakes, but by rebasing before you push no one has to know you did. When the commits are clean, the history is clean. Write good PRs, too, and make sure they translate to good merge commits. Then you can run `git log --first-parent master` and get a pretty decent high-level overview of changes, but with all the other benefits of keeping individual branch commits in history.

yakkityyak 4y ago

I'm betting that a perfectly linear git history is probably easier/nicer to have for people who think of git as a sequence of deltas. That is not how git works, but I can understand the appeal. For all my personal projects I squash and merge everything.

teraflop 4y ago
If you have a Git repository with merge commits that merge changes back into your main branch, all you have to do is "git log --first-parent -m" to get a log that looks exactly as if you had squashed and rebased every change. I'm surprised I don't see more people talking about this option. Sure, the syntax is inelegant, but it seems like it gives you the best of both worlds: you can browse your history as if it was linear, and drill down to the individual commits in a branch only when necessary.
- tsimionescu 4y ago
  Do Github, GitLab, BitBucket, or any other Git UIs support this option? Relatively few people use the command line for inspecting Git history. Not even sure Magit exposes this option directly in most places where it shows history, I believe.
  - zdw 4y ago
    Gerrit has a way to look at all patches uploaded, but only take the last one which should be squashed/rebased, if it's configured that way (The "Fast forward only" option). It results in very clean history, and unmodified commit hashes from a developer's commit, whereas Github's Squash and Merge will mangle the commit message by adding a PR # to it, as well as other comments, which changes the hash. PR #'s are not as good as clean hashes, IMO. As someone who went from an org that was using Gerrit to mandatory Github usage, the latter is definitely a step backwards in code review. That said Github does have a better browsing interface than gitiles.
  - graton 4y ago
    > Relatively few people use the command line for inspecting Git history. Counterpoint: I use the command line all the time to look at Git history.
    - seba_dos1 4y ago
      Same here. Web UIs are pretty cumbersome compared to Git and only really useful for quick lookups in recent history. For anything else, git log is much more convenient.
- graton 4y ago
  > all you have to do is "git log --first-parent -m" What is the `-m` for? Looking at the man page it says: "-m will produce the output only if -p is given as well." Did you mean "--max-parents=1" as a different commenter used with "--first-parent"?
  - seba_dos1 4y ago
    You rarely want to use `--max-parents=1` with `--first-parent` as that will hide all merge commits and merged branches entirely. `-m` is useless here, just use `git log --first-parent`.
  - teraflop 4y ago
    The "-m" doesn't do anything by itself, but it's there in case you want to add an option like "-p", which otherwise wouldn't show a useful diff for a merge commit. With "--first-parent -m -p", the log shows only the diff of the merge commit against its first parent, which is the same as what you would get from squashing.
tsimionescu 4y ago
This depends less on how you conceive of Git, and more on the project's development model. For example, in a team using Git for an internal product, with a centralized repo a main branch and (relatively short-lived) feature branches, the conceptual history of the repo is linear. Seeing all of the merges that everyone did when getting into work is line noise, not likely to be meaningful - so rebasing feature beanches on master every day and then doing squash or FF commits when merging back into master makes the most sense. Alternatively, for an open source project with no "blessed", and with long-lived branches that get contributed by various orgs, trying to make the history appear linear would help nobody. So obviously this kind of model wouldn't work for Linux, but it works better for most in-house software using Git as a centralized VCS with some nice offline history features.

kortex 4y ago

Because it is visual noise. It's really hard to track, especially on the CLI. It's also a lot easier to reason about the codebase through time if it's basically a linear track. We started off with merge commits and moved to squash rebase (team history to team clean), and I gotta say, I absolutely love team clean in the overwhelming majority of cases. The only time team history is handy is as a sort of temporary space on feature branches where you are sorting out complex merges, debugging, or trying different patterns. But all of that gets squashed away onto main eventually.

ilammy 4y ago
> It's really hard to track, especially on the CLI. git log --first-parent --max-parents=1 Now you don't see merge commits. Forbid merge commits with conflict resolution, and you're done.
- Gigachad 4y ago
  How do you forbid the ones with resolution? Genuine question because it seems like merge commits are a black hole where anything could happen and no one would notice.
  - seba_dos1 4y ago
    Just require the merged branch to be fast-forwardable (but don't actually fast-forward it). If it's not, it will be obviously visible in `git log --graph`.
- seba_dos1 4y ago
  You usually don't want to use both arguments at the same time as that will hide the whole merges (both merge commits and merged commits). You can however use one of those arguments to choose what you want to filter out, which is very handy. FWIW, `--max-parents=1` has an alias `--no-merges`.
raggi 4y ago
git log --topo-order

generationP 4y ago

When merge commits involve conflict cleanup, they are very hard to debug (at least with standard tools like tig/gitk/diff; there might be something more advanced). I've seen lines of code disappear into nowhere in merge commits. You can only hope the conflicts were resolved well. Even conflict-free merges can be scary -- you're trusting the system to find the right context. Of course, the same errors can happen on rebase, but at least the resulting commits can easily be inspected.

georgyo 4y ago
The problems here come from the fact that a "merge" commit is just a normal commit with multiple parents. This means that anything can happen inside that merge commit, including add, remove, and modify all the code, even if not touched by a parent. Merge commits are good place for a malicious actor to hide changes.

dataflow 4y ago

Do you have a useful & understandable mental model for "delta"-based operations like "rebase", "revert", etc. for arbitrary commit DAGs? Admittedly I haven't sat down to think about it for very long, but I feel like I'm not the only one who feels like lots of operations (including those) become difficult if not impossible to reason about with nonlinear history.

gregmac 4y ago

I can see it being an issue with people that don't bother to keep clean git history? Eg, that write commit messages like "fixed bug" "oops" "more stuff". I'm on Team Write-Good-Commit-Messages. The key of being on this team is learning interactive rebase: of course everyone makes mistakes, but by rebasing before you push no one has to know you did. When the commits are clean, the history is clean. Write good PRs, too, and make sure they translate to good merge commits. Then you can run `git log --first-parent master` and get a pretty decent high-level overview of changes, but with all the other benefits of keeping individual branch commits in history.