4 ms·

> git bisect pointing to the merge commit as culprit is exactly what should happen in theory, maybe. in practice, this simply does not help if you are looking

by karyon 11y ago

> git bisect pointing to the merge commit as culprit is exactly what should happen in theory, maybe. in practice, this simply does not help if you are looking at massive merge commits. sometimes, the merge goes wrong even with no conflicts, and then you can debug that massive merge with little clue where to start. compare that to rebasing, where you have a hopefully small commit that breaks. you indeed loose the information whether the rebase broke it or the initial version was broken as well, but I don't see the practical difference, it needs to be fixed either way.

golergka 11y ago
Because the notion that commit broke that code is false, and out of that false information you will be able to get a lot of other false ideas about how the code was developed, which will lead to your fix not being entirely correct.
- karyon 11y ago
  That notion is false, right, thus I'd rather think "this commit is not correct anymore". Regarding getting ideas how the code was developed, for the commit that is not correct anymore I have a commit message telling me why it was added. For reasonably small commits, I don't a lot of room for misunderstandings and wrong fixes. This applies if the required changes in your branch are rather small. I think we can agree that rebasing breaks if some changes in master require lots of changes in your branch. But so does merging, as the merge becomes even more horrible and error-prone in that case. Basically, large changes ("real" development) should happen neither in merge commits nor during rebases in my opinion.
  - golergka 11y ago
    > I'd rather think "this commit is not correct anymore" Using the word "anymore" violates the whole abstraction of git, which captures the exact state of the project in each commit. If you look at a commit, there's no "anymore", no other timeframe rather that the commit's; it's either correct or incorrect on it's own. > But so does merging, as the merge becomes even more horrible and error-prone in that case. Why? Just as you don't put all your feature work in one commit, why would you implement a complex merge as one, single merge commit? It makes much more sense to merge each interface change from master to feature branch individually, resulting in atomic merge commits, each of which handles specific aspect, while staying correct.
    - karyon 11y ago
      > If you look at a commit, there's no "anymore", no other timeframe rather that the commit's; it's either correct or incorrect on it's own. this is true but frankly nothing i ever cared about. I think of commits as something that i can change and break and fix through rebasing, amending and the like. This mindset makes you a lot more flexible when handling commits, and when keeping in mind that the commit hashes change while doing that, I don't see any downsides. > It makes much more sense to merge each interface change from master to feature branch individually, resulting in atomic merge commits, each of which handles specific aspect, while staying correct. Then we have different views on what a horrible merge is. For me, that is having dozens of merge conflicts plus multiple necessary changes not indicated by conflicts, and most of those problems need to be resolved before the project compiles and the rest has to be resolved before all tests go green. There is no "while staying correct" in there. And this, working on lots of breakages at once, while needing to fix all of them before tests are green again, this i don't like at all and will be partly mitigated by the rebasing strategy. There certainly are advantages of merge commits, but in my (admittedly limited, especially when talking about larger projects) experience, resolving merge issues does get harder with them.

by karyon 11y ago

golergka 11y ago

Because the notion that commit broke that code is false, and out of that false information you will be able to get a lot of other false ideas about how the code was developed, which will lead to your fix not being entirely correct.

karyon 11y ago
That notion is false, right, thus I'd rather think "this commit is not correct anymore". Regarding getting ideas how the code was developed, for the commit that is not correct anymore I have a commit message telling me why it was added. For reasonably small commits, I don't a lot of room for misunderstandings and wrong fixes. This applies if the required changes in your branch are rather small. I think we can agree that rebasing breaks if some changes in master require lots of changes in your branch. But so does merging, as the merge becomes even more horrible and error-prone in that case. Basically, large changes ("real" development) should happen neither in merge commits nor during rebases in my opinion.
- golergka 11y ago
  > I'd rather think "this commit is not correct anymore" Using the word "anymore" violates the whole abstraction of git, which captures the exact state of the project in each commit. If you look at a commit, there's no "anymore", no other timeframe rather that the commit's; it's either correct or incorrect on it's own. > But so does merging, as the merge becomes even more horrible and error-prone in that case. Why? Just as you don't put all your feature work in one commit, why would you implement a complex merge as one, single merge commit? It makes much more sense to merge each interface change from master to feature branch individually, resulting in atomic merge commits, each of which handles specific aspect, while staying correct.
  - karyon 11y ago
    > If you look at a commit, there's no "anymore", no other timeframe rather that the commit's; it's either correct or incorrect on it's own. this is true but frankly nothing i ever cared about. I think of commits as something that i can change and break and fix through rebasing, amending and the like. This mindset makes you a lot more flexible when handling commits, and when keeping in mind that the commit hashes change while doing that, I don't see any downsides. > It makes much more sense to merge each interface change from master to feature branch individually, resulting in atomic merge commits, each of which handles specific aspect, while staying correct. Then we have different views on what a horrible merge is. For me, that is having dozens of merge conflicts plus multiple necessary changes not indicated by conflicts, and most of those problems need to be resolved before the project compiles and the rest has to be resolved before all tests go green. There is no "while staying correct" in there. And this, working on lots of breakages at once, while needing to fix all of them before tests are green again, this i don't like at all and will be partly mitigated by the rebasing strategy. There certainly are advantages of merge commits, but in my (admittedly limited, especially when talking about larger projects) experience, resolving merge issues does get harder with them.