3 ms·

> git will not accept the push because it's not on top of current master branch, person B needs to fetch and merge/rebase before pushing again. Hmm...that seem

> git will not accept the push because it's not on top of current master branch, person B needs to fetch and merge/rebase before pushing again. Hmm...that seems like a feature to me, not a bug. To me nothing of substance should happen in the repository, it should all happen in the local working directory. ¯\_(ツ)_/¯

bluepanda1234 3y ago
Was going to say exactly this, though I do wonder if it's just me being too set in my thinking around how I think version control should work.
davorak 3y ago
> To me nothing of substance should happen in the repository, The idea is that with pijul nothing of substance would happen on the server in this example, it is the same process that would happen if you were doing it all locally.
- mpweiher 3y ago
  Hmm...so if something did need to happen, pijul would also reject and I would have to pull, do the local edits until everything is consistent and then push, just like git. So it's a low-impact optimization of the fast path? But actually, how does pijul know there are no conflicts? Textually? https://pijul.org/manual/conflicts.html https://pijul.org/manual/conflicts.html Hmmm...yeah looks like it's purely textual. Er, no. There can be semantic conflicts that I need to resolve that do not conflict textually. The test suite needs to be green locally on my machine, and then we replace the Top of Tree wholesale with the code that passed the tests locally on my machine. So to me this feature of pijul is clearly an anti-feature, a bug, and the git behavior is correct.
  - baq 3y ago
    You’re describing CI, not git nor pijul, nor any other version control system.
  - davorak 3y ago
    > Hmm...so if something did need to happen, pijul would also reject and I would have to pull, do the local edits until everything is consistent and then push, just like git. Unlike git, pijul has first class conflicts, pijul unlike git does not reject in this example. My knowledge is limited, but from my testing that means the conflict exists in the history, at least if your merge style allows for that(similar to how in git you can choose to always rebase or use merge commits). The conflict is resolved with a new patch. I did not spot much in the documentation with a quick search but on the man page there is a small blurb on first class conflicts > First-class conflicts In Pijul, conflicts are not modelled as a "failure to merge", but rather as the standard case. Specifically, conflicts happen between two changes, and are solved by one change. The resolution change solves the conflict between the same two changes, no matter if other changes have been made concurrently. Once solved, conflicts never come back. - from https://pijul.org/ https://pijul.org/

bluepanda1234 3y ago

Was going to say exactly this, though I do wonder if it's just me being too set in my thinking around how I think version control should work.

davorak 3y ago

> To me nothing of substance should happen in the repository, The idea is that with pijul nothing of substance would happen on the server in this example, it is the same process that would happen if you were doing it all locally.

mpweiher 3y ago
Hmm...so if something did need to happen, pijul would also reject and I would have to pull, do the local edits until everything is consistent and then push, just like git. So it's a low-impact optimization of the fast path? But actually, how does pijul know there are no conflicts? Textually? https://pijul.org/manual/conflicts.html https://pijul.org/manual/conflicts.html Hmmm...yeah looks like it's purely textual. Er, no. There can be semantic conflicts that I need to resolve that do not conflict textually. The test suite needs to be green locally on my machine, and then we replace the Top of Tree wholesale with the code that passed the tests locally on my machine. So to me this feature of pijul is clearly an anti-feature, a bug, and the git behavior is correct.
- baq 3y ago
  You’re describing CI, not git nor pijul, nor any other version control system.
- davorak 3y ago
  > Hmm...so if something did need to happen, pijul would also reject and I would have to pull, do the local edits until everything is consistent and then push, just like git. Unlike git, pijul has first class conflicts, pijul unlike git does not reject in this example. My knowledge is limited, but from my testing that means the conflict exists in the history, at least if your merge style allows for that(similar to how in git you can choose to always rebase or use merge commits). The conflict is resolved with a new patch. I did not spot much in the documentation with a quick search but on the man page there is a small blurb on first class conflicts > First-class conflicts In Pijul, conflicts are not modelled as a "failure to merge", but rather as the standard case. Specifically, conflicts happen between two changes, and are solved by one change. The resolution change solves the conflict between the same two changes, no matter if other changes have been made concurrently. Once solved, conflicts never come back. - from https://pijul.org/ https://pijul.org/