3 ms·
It depends on that context, if they're the end of day "work in progress" or "typo" commits, I don't see the value in retaining those. A non-linear commit histo
by cube00 4y ago
It depends on that context, if they're the end of day "work in progress" or "typo" commits, I don't see the value in retaining those.
A non-linear commit history is much more difficult to run a bisect on which was enough to sell linear for me.
- donatj 4y agoThe bisect might be easier to do, but it's vastly less useful if you're looking for why and not what since the commits are not actually the authors originals and the state of the project you find is not the state the author authored them within.
- cube00 4y agoFor us only the original authors squash and tidy up their own commits so they can add as much context as they want. That's not to say each PR is one commit, if there are multiple distinct parts of a PR that could be cherry picked in a way that they make sense on their own they'd still be separate commits.
- Izkata 4y ago> That's not to say each PR is one commit This thread is about squash merge, which converts the whole branch into a single commit.
- mildred593 4y agotypo commits might be really useful, especially if you can bisect a bug from one of those commits. it happened to me.
- WorldMaker 4y ago`git bisect --first-parent` is just as easy as a bisect on linear history. (It just follows the "linear" line down merge commits via their first parent, which by convention should be their "base" parent.) Plus it gives you the option to bisect "inside" a branch if you need to inspect something "low level" once you've narrowed down the "branch" based on merge commit. I think if `--first-parent` were the default to git bisect a lot more people would care a lot less about "linear commit history". But it is still an easy flag to apply yourself.