4 ms·

> The tool developers want every commit to be feature-complete and that it won't cause broken builds at least in the master branch. This is impossible to achiev

> The tool developers want every commit to be feature-complete and that it won't cause broken builds at least in the master branch. This is impossible to achieve in the regular commit-merge workflow.You need to add the interactive rebases to achieve the goal. Why is this impossible to do with a commit-merge workflow? If I do work on a development branch, then merge it into the main branch, only the merge commit appears in the main branch, and that merge commit has the final feature-complete commit. The main branch then has an unbroken sequence of feature-complete commits. The only two complications are (1) avoiding fast-forward merges with the --no-ff flag and (2) viewing the history using the --first-parent flag. The first ensures that you always have a merge commit, even in cases where the history could be accurately represented without it, and the second avoids display of the development commits.

noahtallen 4y ago
I think the idea is that in a branch after a rebase, you have “main” with your new branch commits on top. This is exactly what it’d be like after merging to main, so you can test the branch with a high degree of confidence it’ll work correctly after merging.
- MereInterest 4y ago
  Yes, but that only says that rebasing is no worse than merging with respect to testing the branch ahead of time. With respect to identifying when a bug was introduced, or the intended effect of a change, rebasing is worse because it cannot distinguish between a bug introduced during a feature implementation and a bug introduced during the rebase. The history that would be needed to distinguish between those cases has been thrown away.
  - rgoulter 4y ago
    Even then, it's worth distinguishing between: - Work in progress: My change request has been open for some time; I will rebase it against the master branch. - Accepting changes into master branch: `git merge` or `rebase + commit` or `rebase + squash + commit`. I don't think there's any practical downside to rebasing WIP branches.
geysersam 4y ago
> Why is this impossible to do with a commit-merge workflow? Some change in the main branch (after your feature branch diverged) could break the new feature, without causing a merge conflict.
- counttheforks 4y ago
  You could use `--no-ff` to force a merge commit and then amend it. Not very common, though.
- MereInterest 4y ago
  This can happen for either a rebase or a merge, though. In the case of a rebase, you’re left with commit(s) on top of main, which are entirely broken. In the case of a rebase, you have a working dev branch, a working main branch up to the merge, and a merge commit with broken code. The merge results in a much better state, because you have a working version to compare against. In addition, the history makes it clear that the merge caused the breakage, and that it wasn’t solely an issue with the new feature.
cryptonector 4y ago
A merge workflow results in convoluted history. A rebase workflow lets you produce nice, useful-to-others, linear history.
- deleted 4y ago
  [deleted]
- TeMPOraL 4y ago
  I wonder if part of the issue isn't tooling defaults. In general, I always find grap > tree > linear [0], but not so with git commits. This might speak to my lack of proficiency with git, but I always find merge commits to be annoying, useless noise. Particularly on a codebase with lost of regular contributors (i.e. at work), there are occasions when I view the log, only to be greeted by a "Christmas tree" of a dozen commits that all say "Merged ${xyz} into develop". So even though rebasing loses some context through linearization, it at least doesn't add any noise commits to the log. (Yes, there probably is some magic switch in git log that reduces the merge commit noise. But approximately nobody knows it, looking how the primary argument for squash+rebase workflow I've seen in teams I worked with was always "because it avoids the Christmas tree/chainsaw and overall denoises the log".) -- [0] - For example this is a reason I vastly prefer HN and Reddit to phpBB-style boards. I find linear threads to be stupidly bad UX for discussing a topic. I know many people disagree, but I've been participating daily in enough forums of this style, some pretty high-volume ones, that I know what invariably happens is people recreating threading with quote-replies and lots and lots of pointless scrolling.
  - cryptonector 4y ago
    Sun used a rebase workflow on Solaris from 1992 onwards (well before Git came along), and the reason is that following non-linear (merge) history in a project that thousands contribute to just doesn't scale well for human minds. (Back then Sun used the awful Teamware.) For sure the tooling then was worse than now, but linear history is just very nice to work with because our brains are not that awesome. Comment threads and code history are vastly different things. The latter in the end is always linearized and the merge turds (if present) encode bits of history on the side. The former really are tree-like, and also not about code but about natural language.

noahtallen 4y ago

I think the idea is that in a branch after a rebase, you have “main” with your new branch commits on top. This is exactly what it’d be like after merging to main, so you can test the branch with a high degree of confidence it’ll work correctly after merging.

MereInterest 4y ago
Yes, but that only says that rebasing is no worse than merging with respect to testing the branch ahead of time. With respect to identifying when a bug was introduced, or the intended effect of a change, rebasing is worse because it cannot distinguish between a bug introduced during a feature implementation and a bug introduced during the rebase. The history that would be needed to distinguish between those cases has been thrown away.
- rgoulter 4y ago
  Even then, it's worth distinguishing between: - Work in progress: My change request has been open for some time; I will rebase it against the master branch. - Accepting changes into master branch: `git merge` or `rebase + commit` or `rebase + squash + commit`. I don't think there's any practical downside to rebasing WIP branches.

geysersam 4y ago

> Why is this impossible to do with a commit-merge workflow? Some change in the main branch (after your feature branch diverged) could break the new feature, without causing a merge conflict.

counttheforks 4y ago
You could use `--no-ff` to force a merge commit and then amend it. Not very common, though.
MereInterest 4y ago
This can happen for either a rebase or a merge, though. In the case of a rebase, you’re left with commit(s) on top of main, which are entirely broken. In the case of a rebase, you have a working dev branch, a working main branch up to the merge, and a merge commit with broken code. The merge results in a much better state, because you have a working version to compare against. In addition, the history makes it clear that the merge caused the breakage, and that it wasn’t solely an issue with the new feature.

cryptonector 4y ago

A merge workflow results in convoluted history. A rebase workflow lets you produce nice, useful-to-others, linear history.

deleted 4y ago
[deleted]
TeMPOraL 4y ago
I wonder if part of the issue isn't tooling defaults. In general, I always find grap > tree > linear [0], but not so with git commits. This might speak to my lack of proficiency with git, but I always find merge commits to be annoying, useless noise. Particularly on a codebase with lost of regular contributors (i.e. at work), there are occasions when I view the log, only to be greeted by a "Christmas tree" of a dozen commits that all say "Merged ${xyz} into develop". So even though rebasing loses some context through linearization, it at least doesn't add any noise commits to the log. (Yes, there probably is some magic switch in git log that reduces the merge commit noise. But approximately nobody knows it, looking how the primary argument for squash+rebase workflow I've seen in teams I worked with was always "because it avoids the Christmas tree/chainsaw and overall denoises the log".) -- [0] - For example this is a reason I vastly prefer HN and Reddit to phpBB-style boards. I find linear threads to be stupidly bad UX for discussing a topic. I know many people disagree, but I've been participating daily in enough forums of this style, some pretty high-volume ones, that I know what invariably happens is people recreating threading with quote-replies and lots and lots of pointless scrolling.
- cryptonector 4y ago
  Sun used a rebase workflow on Solaris from 1992 onwards (well before Git came along), and the reason is that following non-linear (merge) history in a project that thousands contribute to just doesn't scale well for human minds. (Back then Sun used the awful Teamware.) For sure the tooling then was worse than now, but linear history is just very nice to work with because our brains are not that awesome. Comment threads and code history are vastly different things. The latter in the end is always linearized and the merge turds (if present) encode bits of history on the side. The former really are tree-like, and also not about code but about natural language.