4 ms·

In both cases we're just "hoping" that the result is what we want. Merging is acknowledging the parallel development and explicitly dealing with it; rebasing is

by feoren 3y ago

In both cases we're just "hoping" that the result is what we want. Merging is acknowledging the parallel development and explicitly dealing with it; rebasing is pretending it never happened and applying my patches on top of a codebase that I have never seen before. In my experience, rebasing is much more likely to fail in weird and dangerous ways. But I'll admit Git's merging leaves a lot to be desired too -- that's part of what I'm complaining about, and what attracts people to rebase.

lifeisstillgood 3y ago
Then I think that the complexity is kind of inherent. Firstly it's only a codebase I have never seen before because I am not keeping up with the changes. Ideally i will pause during rebase carefully read the commits which will include long thoughtful messages laying out important implications, and my tooling will make clear where the conflicts lie, and how test coverage is affected. We won't ever just grep for <<<<<< and try and remember which HEAD means - is that mine or yours? I am making changes against an evolving codebase. Either I am talking with people editing that codebase and we are in sympathy or we are hoping a VCS will solve our political and organisational problems. I honestly think having time to argue about the best way to solve a problem amoung a team is the best solution - let the team talk argue and decide and they will barely need a VCS. If you cannot "spare the time we must deliver" you got other problems Edit: Look honestly it's all patches. That's the atomic level. And to my mind, having you gather the freshest version of the codebase then apply your chnage son top is the sanest cleanest approach. The same merge conflict resolution applies - I agree. (basically line conflicts). But what's the option? Anything else gets weirder faster (seen some trying to understand conflicts in functions, etc)
deleted 3y ago
[deleted]

by feoren 3y ago

lifeisstillgood 3y ago

Then I think that the complexity is kind of inherent. Firstly it's only a codebase I have never seen before because I am not keeping up with the changes. Ideally i will pause during rebase carefully read the commits which will include long thoughtful messages laying out important implications, and my tooling will make clear where the conflicts lie, and how test coverage is affected. We won't ever just grep for <<<<<< and try and remember which HEAD means - is that mine or yours? I am making changes against an evolving codebase. Either I am talking with people editing that codebase and we are in sympathy or we are hoping a VCS will solve our political and organisational problems. I honestly think having time to argue about the best way to solve a problem amoung a team is the best solution - let the team talk argue and decide and they will barely need a VCS. If you cannot "spare the time we must deliver" you got other problems Edit: Look honestly it's all patches. That's the atomic level. And to my mind, having you gather the freshest version of the codebase then apply your chnage son top is the sanest cleanest approach. The same merge conflict resolution applies - I agree. (basically line conflicts). But what's the option? Anything else gets weirder faster (seen some trying to understand conflicts in functions, etc)

deleted 3y ago

[deleted]