3 ms·

I cannot grasp that at all. To rebase I take your patches, apply them, then I apply my patches, fixing any trip ups. You "got in" first, so I get to do the wo

I cannot grasp that at all. To rebase I take your patches, apply them, then I apply my patches, fixing any trip ups. You "got in" first, so I get to do the work. It seems simple to me - far more than hoping merges do what we both meant. Conceptually, it's patches all the way down - anything else is to me suspect ... might be me not being big brained enough :-)

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]
sam_bristow 3y ago
I've been keeping an eye on the Pijul[1] VCS which goes all-in on the whole "theory of patches" thing. I don't expect Git will be going anywhere for a long time, bjt it's interesting to think about what could be next. [1]https://pijul.org/ https://pijul.org/

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]

sam_bristow 3y ago

I've been keeping an eye on the Pijul[1] VCS which goes all-in on the whole "theory of patches" thing. I don't expect Git will be going anywhere for a long time, bjt it's interesting to think about what could be next. [1]https://pijul.org/ https://pijul.org/