3 ms·

With files not identified by file name, I'm curious whether pijul is able to reconcile two independent additions of the same file. I suppose there'll have to be

With files not identified by file name, I'm curious whether pijul is able to reconcile two independent additions of the same file. I suppose there'll have to be some custom logic to deal with this kind of conflict? E.g.: Alice creates change A: add file /README (identified by hash x) Bob creates change B: add file /README (identified by hash y) C: adds a copyright header to README Now Bob pulls from Alice, and wants Alice's README contents (change A). Does pijul notice conflicts between A & B? If Bob records a change resolving the conflict between A & B by keeping A, will it be possible to apply C on top of this?

pmeunier 6y ago
Pijul will treat that as a conflict indeed, in particular because it has no way to tell that Alice and Bob meant the same thing when adding that file. A README is a simple example, but what about a module split from a larger module during a refactoring? Even if the filenames added by Alice and Bob match, how can we know they're meant to be the same?
- olau 6y ago
  This seems (somewhat?) orthogonal to what you're doing with Pijul at the moment, but I feel that auto-merging to avoid manual handling of obvious cases is somewhat underdeveloped in modern version control systems. Perhaps that's just because people aren't talking about it - I've actually never looked at git's interface for automerging. Even though I have a couple of examples of spurious conflicts that come up regularly.
  - pmeunier 6y ago
    There are two separate things: - Git does have spurious conflicts coming back for no reason. The problem is so real that there's even a `rerere` command to take care of it. - Pijul has "minimal" conflicts, in the sense that these are conflicts you can't possibly make sense of without human guidance. You get the guarantee that fixed conflicts don't come back. Unfortunately, "obvious" cases are never completely obvious: let's say Alice and Bob both add a case to a C function, and both change `#define NUMBER_OF_CASES 42` to `#define NUMBER_OF_CASES 43`.

pmeunier 6y ago

Pijul will treat that as a conflict indeed, in particular because it has no way to tell that Alice and Bob meant the same thing when adding that file. A README is a simple example, but what about a module split from a larger module during a refactoring? Even if the filenames added by Alice and Bob match, how can we know they're meant to be the same?

olau 6y ago
This seems (somewhat?) orthogonal to what you're doing with Pijul at the moment, but I feel that auto-merging to avoid manual handling of obvious cases is somewhat underdeveloped in modern version control systems. Perhaps that's just because people aren't talking about it - I've actually never looked at git's interface for automerging. Even though I have a couple of examples of spurious conflicts that come up regularly.
- pmeunier 6y ago
  There are two separate things: - Git does have spurious conflicts coming back for no reason. The problem is so real that there's even a `rerere` command to take care of it. - Pijul has "minimal" conflicts, in the sense that these are conflicts you can't possibly make sense of without human guidance. You get the guarantee that fixed conflicts don't come back. Unfortunately, "obvious" cases are never completely obvious: let's say Alice and Bob both add a case to a C function, and both change `#define NUMBER_OF_CASES 42` to `#define NUMBER_OF_CASES 43`.