Timeline for Why do so many projects prefer "git rebase" over "git merge"?
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 2, 2021 at 15:17 | comment | added | Izkata | @Faissaloo My examples have nothing to do with resolving conflicts, it's more along the lines of: if a function was simplified and had an argument removed in branch A, while a simultaneous branch B started using that argument in new call in a different part of the code, there would be no failures until they were merged together (and no merge conflicts at all). Whereas in a rebase workflow, bisect would point at the specific commit in the later-applied branch where it started failing. | |
| Feb 2, 2021 at 11:30 | comment | added | 0x777C | I don't see why rebasing would help here unless you're not merging regularly, in which case rebasing would also be a problem because you'd end up having to resolve conflicts for multiple commits | |
| Oct 17, 2014 at 12:46 | comment | added | Lan | @Izkata Why are you using bisect? Because bugs/mistakes happen. It's a humbling reality. Maybe "dragging the mouse to the left" was not a part of the automated/manual testing list before and now we notice that that feature is broken but we know it used to work. | |
| Oct 16, 2014 at 20:40 | comment | added | Izkata |
@JohnDaniel And D uses it wrong why are you ever making commits you haven't tested? That seems like the source of the confusion in your example...
|
|
| Oct 16, 2014 at 20:31 | comment | added | Lan | @Izkata Say the issue is "The program crashes when the user moves their mouse left". Say E removes an old Mouse API. Say commit B says it changed where it called the Mouse Package and commit D says "Now using optional 2.x Mouse Package API". And D uses it wrong. If B can't be run, either you're debugging the wrong place or now can't use bisect since you don't know whether to go left or right (trying both directions doesn't work since C is broken too). If B can be run, you're lulled into thinking it was the change of when it called the mouse package instead of interacting with it wrong. | |
| Oct 16, 2014 at 18:09 | comment | added | Izkata |
@JohnDaniel Assuming commits B, C, and D were made in order, then B and C do contain an issue - they're no longer compatible with the pushed code. D won't be the source of that problem unless you intentionally changed the order of your 3 commits. And, as I describe at the beginning of my answer, your commit message for B should contain enough information for you to fix it in a new commit (and if necessary, rebase -i and squash it into B so that the commit passes again)
|
|
| Oct 16, 2014 at 16:27 | comment | added | Lan | Really disagree with this answer. Rebasing destroys bisect's utility at times. Except for the head commits of a rebase, the commits from a rebase may not be runnable. Example: You branched at A and made B,C, D, someone pushed E. You're B and C and work but rebased on E, you're B and C are unrunnable or are runnable and don't work. Best case is you give up, worst case you think B or C contains the issue when in reality it is D. | |
| Dec 12, 2013 at 14:12 | audit | First posts | |||
| Dec 12, 2013 at 14:50 | |||||
| Nov 19, 2013 at 13:52 | comment | added | Izkata | @KarlBielefeldt Look at the very last sentence in my answer. You can have both, AFAIK. | |
| Nov 19, 2013 at 13:49 | comment | added | Andyz Smith | @KarlBielefeldt so, don't rebase until you are pretty good and sure that what you have is bug-free because once you do, all the previous changes go off-book and changes that occurred in the last six months can't be distinguished from older, almost certainly perfect code. | |
| Nov 19, 2013 at 13:39 | comment | added | Karl Bielefeldt |
But the merge is the problem, so you want a merge commit as a bisect result. It's easy enough to find the individual commits with a blame or a different bisect if you want to dig deeper. With a linear history, the merge is done off book, so you can no longer tell a bad merge was the problem. It just looks like an idiot using an argument that doesn't exist, especially if the argument was removed several commits previous. Trying to figure out why he would do that is much more difficult when you destroy the history.
|
|
| Nov 19, 2013 at 5:02 | history | edited | Izkata | CC BY-SA 3.0 |
Mixed up which branch was which
|
| Nov 19, 2013 at 5:01 | comment | added | Andyz Smith | for me, i prefer the whole history. Because one day Imay discover that what I thought was a known good baseline actually contained a change that produced a bug. But it wasn't noticed and was thought to be a good baeeline. If I am working on on a local repo, with only the rebase up to now log, i can't tell where changes to a suspect function were made. they've been rebased out of my history, allowing me to ignore them blythely, conveniently, until it's totally not convenient, because i can't find the change that produced a bug I uncovered. Hmm i dont even use git but thats my two cents | |
| Nov 19, 2013 at 4:58 | comment | added | Izkata |
@Philip I'm a little hesitant to do so, as I've only used git for a few months on small personal projects, never on a team. But when tracking what I've done recently, being able to see the flow of commits across branches in gitk --all is extremely useful (especially since I usually have 3-ish branches at any given time, and switch between them each day depending on my mood at the time).
|
|
| Nov 19, 2013 at 4:53 | comment | added | Philip | Thanks for this explanation. Can you expand on why you still prefer merging? I know a lot of people prefer merging to rebasing in most situations, but I've never been able to understand why. | |
| Nov 19, 2013 at 4:20 | history | answered | Izkata | CC BY-SA 3.0 |