4 ms·

> you can "unapply" (or "unrecord") changes made in the past, without having to change the identity of new patches (without "rebasing", in git terms). So I the

> you can "unapply" (or "unrecord") changes made in the past, without having to change the identity of new patches (without "rebasing", in git terms). So I the identity of a patch doesn't depend on history? Nice! I wish git was like that. In fact, every time I rebase on master, I wish so.

guitarbill 6y ago
i'm not sure if this project is different, but patches can suck really bad. an example of this are mercurial queues (mq). with no history/ancestry, the merge behaviour can be horrible. for even medium-size teams, it goes downhill quickly. IMO, it's fucking broken and a huge waste of time. of course, it's possible i don't get mq. but i'll take git any day of the week over mercurial + mq, at least git works and doesn't loose my work as often. (believe it or not, this is easier to do with mq than git (!).) maybe pijul is different, but their "conflict" doco doesn't fill me with confidence: https://pijul.org/manual/conflicts.html https://pijul.org/manual/conflicts.html
- gnufx 6y ago
  > maybe pijul is different No "maybe"; that's the point. Why does modelling something fundamental, like conflicts, decrease confidence in the approach?
  - guitarbill 6y ago
    > Patches can be applied to a conflicting repository, leaving the conflict resolution for later. (from the docs) but you still have to resolve the conflicts at some point, right? and it doesn't say how this is done. so it isn't clear if this approach is less painful in practice when you apply a bunch of patches.
    - gnufx 6y ago
      I haven't used pijul, but I'm familiar with darcs and manually resolving the conflict with a new patch. You still have the conflicting patches, which you can manipulate. There's no claim of magic resolution, and I don't see why having it in the model is a negative.
- garmaine 6y ago
  Mercurial is not pijul/darcs. They’re fundamentally different at the core.
- a1369209993 6y ago
  > > So I the identity of a patch doesn't depend on history? > with no history/ancestry, the merge behaviour can be horrible. It's possible to have history associated with a commit without making that history a immutable part of the commit's cryptographically-enforced identity.
  - fiddlerwoaroof 6y ago
    The cryptographic guarantee that a commit with the same identity represents the same codebase state is the killer feature of git: it’s great to be able to trust the history of a repository that way.
    - a1369209993 6y ago
      > The cryptographic guarantee that a commit with the same identity represents the same codebase state is the killer feature of git Um, no? I don't think anyone in the history of git has ever reasoned "Well, I'd like to use this other VCS, but git is really useful for my use case of working with co-developers who are so untrustworthy that I need cryptographic assurance they haven't tampered with the history of the repository, but who I nonetheless trust not to inject Underhander C Contest[0]-style bugs in the code or otherwise deliberately sabotage things that aren't the history.". The killer feature of git is operating on the repository and its history as a graph structure, which works even if commit ids are completely non-cryptographic GUIDs. (In the single-user case you could even use sequential integers, but that doesn't scale.) Cryptographic assurance is nice to have (dumb mistakes and unexpected malice happen to everyone), but it's worth trading away if the resulting features are good enough to justify the trade-off. 0: http://underhanded-c.org/ http://underhanded-c.org/
      - whatevah5982 6y ago
        As a single developer or a team working in the same organization you can ignore this property, however in a distributed VCS it is pretty much a defining and essential feature. Guaranteeing that the history is the same is paramount to ensure that the same operation on two repositories which are _supposed_ to be identical will yield the same results. This is what allows you to merge back history from a forked repository over which you have no control with confidence. You don't necessarily need that property, true. You also don't necessarily need to make it mandatory. However if you want to play in the distributed VCS game, you'd better have something equivalent that can give you the same guarantee.
- juped 6y ago
  Patch theory VCSes are, IMO, very much not the future of VCS, but they're an important research project, and the future will have learned from them. Git is definitely the present of VCS, even if it was adopted for all the wrong reasons (not Git's fault).
kmeisthax 6y ago
That's by design: if you know a Git commit ID, you automatically also know the history hasn't been tampered with (modulo hash collisions). Linus specifically wanted a system where development history cannot change behind developer's backs. Given that the other big design constraint of Git was distributed version control, I'd argue that this is a very important property to have. You don't want to pull in someone else's branch and suddenly have all your own developer history change.

guitarbill 6y ago

i'm not sure if this project is different, but patches can suck really bad. an example of this are mercurial queues (mq). with no history/ancestry, the merge behaviour can be horrible. for even medium-size teams, it goes downhill quickly. IMO, it's fucking broken and a huge waste of time. of course, it's possible i don't get mq. but i'll take git any day of the week over mercurial + mq, at least git works and doesn't loose my work as often. (believe it or not, this is easier to do with mq than git (!).) maybe pijul is different, but their "conflict" doco doesn't fill me with confidence: https://pijul.org/manual/conflicts.html https://pijul.org/manual/conflicts.html

gnufx 6y ago
> maybe pijul is different No "maybe"; that's the point. Why does modelling something fundamental, like conflicts, decrease confidence in the approach?
- guitarbill 6y ago
  > Patches can be applied to a conflicting repository, leaving the conflict resolution for later. (from the docs) but you still have to resolve the conflicts at some point, right? and it doesn't say how this is done. so it isn't clear if this approach is less painful in practice when you apply a bunch of patches.
  - gnufx 6y ago
    I haven't used pijul, but I'm familiar with darcs and manually resolving the conflict with a new patch. You still have the conflicting patches, which you can manipulate. There's no claim of magic resolution, and I don't see why having it in the model is a negative.
garmaine 6y ago
Mercurial is not pijul/darcs. They’re fundamentally different at the core.
a1369209993 6y ago
> > So I the identity of a patch doesn't depend on history? > with no history/ancestry, the merge behaviour can be horrible. It's possible to have history associated with a commit without making that history a immutable part of the commit's cryptographically-enforced identity.
- fiddlerwoaroof 6y ago
  The cryptographic guarantee that a commit with the same identity represents the same codebase state is the killer feature of git: it’s great to be able to trust the history of a repository that way.
  - a1369209993 6y ago
    > The cryptographic guarantee that a commit with the same identity represents the same codebase state is the killer feature of git Um, no? I don't think anyone in the history of git has ever reasoned "Well, I'd like to use this other VCS, but git is really useful for my use case of working with co-developers who are so untrustworthy that I need cryptographic assurance they haven't tampered with the history of the repository, but who I nonetheless trust not to inject Underhander C Contest[0]-style bugs in the code or otherwise deliberately sabotage things that aren't the history.". The killer feature of git is operating on the repository and its history as a graph structure, which works even if commit ids are completely non-cryptographic GUIDs. (In the single-user case you could even use sequential integers, but that doesn't scale.) Cryptographic assurance is nice to have (dumb mistakes and unexpected malice happen to everyone), but it's worth trading away if the resulting features are good enough to justify the trade-off. 0: http://underhanded-c.org/ http://underhanded-c.org/
    - whatevah5982 6y ago
      As a single developer or a team working in the same organization you can ignore this property, however in a distributed VCS it is pretty much a defining and essential feature. Guaranteeing that the history is the same is paramount to ensure that the same operation on two repositories which are _supposed_ to be identical will yield the same results. This is what allows you to merge back history from a forked repository over which you have no control with confidence. You don't necessarily need that property, true. You also don't necessarily need to make it mandatory. However if you want to play in the distributed VCS game, you'd better have something equivalent that can give you the same guarantee.
juped 6y ago
Patch theory VCSes are, IMO, very much not the future of VCS, but they're an important research project, and the future will have learned from them. Git is definitely the present of VCS, even if it was adopted for all the wrong reasons (not Git's fault).

kmeisthax 6y ago

That's by design: if you know a Git commit ID, you automatically also know the history hasn't been tampered with (modulo hash collisions). Linus specifically wanted a system where development history cannot change behind developer's backs. Given that the other big design constraint of Git was distributed version control, I'd argue that this is a very important property to have. You don't want to pull in someone else's branch and suddenly have all your own developer history change.