3 ms·
> You can squash into master without losing the history This is otherwise known as a merge. A single atomic change to master, referencing only the final files
by MaulingMonkey 11y ago
> You can squash into master without losing the history
This is otherwise known as a merge. A single atomic change to master, referencing only the final files, with the first parent referencing the previous master that was also "not" broken.
It has only one change: A second parent, referencing the more accurate history.
- furyferret 11y agoWhat you're describing is definitely a squash.
- MaulingMonkey 11y agoGiven: http://robey.lag.net/images/no-ff-5.png http://robey.lag.net/images/no-ff-5.png If we start without M, and start with master=R2, temporary-feature-branch=R5, I expect the following outcomes: "squash" will leave us with master=M, and the graph R1 -> R2 -> M. Once temporary-feature-branch is deleted, R3-R5 are forever lost. "merge" will leave us with master=M, and the graph R1 -> R2 -> M, + R2 -> R3 -> R4 -> R5 -> M "rebase" will leave us with master=R5, and the graph R1 -> R2 -> R3 -> R4 -> R5. Once temporary-feature-branch is deleted, The first case loses the history of the code, and thus can't be what we're talking about. If you call the second case "squash" I find that very confusing. It's also not what github is referring to when talking about "squash your commits" in the parent article, they're talking about the first case. Now, git confuses the issue a bit too - perhaps I should be labeling the second case a "non-fast-forward merge", but I'd still find that clearer than "squash without losing the history."