4 ms·

> As for patch vs snapshot, that's arguing at the implementation level ?? Thats the core of any version control system, namely "what exactly am I versioning?"

by isr 8y ago

> As for patch vs snapshot, that's arguing at the implementation level ?? Thats the core of any version control system, namely "what exactly am I versioning?". For anything beyond the trivial use case (and "trivial uses" probably encompass a large majority of all usage of version control systems, so thats not to be sniffed at), this fundamental difference of "what am I versioning" impacts, well, everything. For one thing, dealing explicitly with patches rather than snapshots means you can almost have ad-hoc branches, on the fly, AFTER the fact (ie: you only realised you wanted to separate out some commits long after you actually did them). You can't do that with git, where every "patch" is really part of a linear series of commit where the parent of each is hardcoded into the commit blob. Not without rewriting the history. Or revisiting the past, in the future (by writing undo commits, and branching after). Or however you want to do it.

emmelaich 8y ago
> Thats the core of any version control system, namely "what exactly am I versioning?". I would say that's less fundamental than answering "give me the exact state of the repo at time t" > You can't do that with git, Maybe I misunderstand but you can branch from some arbitrary point and cherry-pick to your heart's content. Of course the hashes won't be the same but does that matter?
- pas 8y ago
  With "patch theory" the VCS can tell you which patches depend on which patches, even if they look like a linear "tree", it helps you get the same result. Of course you can do it with git, but it helps you get there faster. Git uses some heuristics to make things smooth, but when it fails, it fails bad. Patch theory handles those, and it cannot "fail", it simply states where the conflict is. (On patch level, not just that these files happen to conflict because these diffs conflict after a lot of rebase-rewrite.) Which will be exact, not heuristic driven and implementation dependent, like in Git.
- pmeunier 8y ago
  > I would say that's less fundamental than answering "give me the exact state of the repo at time t" This is indeed a very important question when you're working alone, but the notion of "at time t" changes when many people work in parallel. This is why Pijul has two notions of time: - Patches, which always commute when produced in parallel. - The sequences of patches applied locally to a branch. Alice and Bob working together can have the same patches and a different application order, what matters for the contents of their file is the set of patches only. > Of course the hashes won't be the same but does that matter? It does matter a lot sometimes, for instance if you cherry-pick, solve a conflict, and cherry pick again from the same branch, the fact that Git changes the hashes will make the conflict reappear the second time you cherry-pick.

by isr 8y ago

emmelaich 8y ago

> Thats the core of any version control system, namely "what exactly am I versioning?". I would say that's less fundamental than answering "give me the exact state of the repo at time t" > You can't do that with git, Maybe I misunderstand but you can branch from some arbitrary point and cherry-pick to your heart's content. Of course the hashes won't be the same but does that matter?

pas 8y ago
With "patch theory" the VCS can tell you which patches depend on which patches, even if they look like a linear "tree", it helps you get the same result. Of course you can do it with git, but it helps you get there faster. Git uses some heuristics to make things smooth, but when it fails, it fails bad. Patch theory handles those, and it cannot "fail", it simply states where the conflict is. (On patch level, not just that these files happen to conflict because these diffs conflict after a lot of rebase-rewrite.) Which will be exact, not heuristic driven and implementation dependent, like in Git.
pmeunier 8y ago
> I would say that's less fundamental than answering "give me the exact state of the repo at time t" This is indeed a very important question when you're working alone, but the notion of "at time t" changes when many people work in parallel. This is why Pijul has two notions of time: - Patches, which always commute when produced in parallel. - The sequences of patches applied locally to a branch. Alice and Bob working together can have the same patches and a different application order, what matters for the contents of their file is the set of patches only. > Of course the hashes won't be the same but does that matter? It does matter a lot sometimes, for instance if you cherry-pick, solve a conflict, and cherry pick again from the same branch, the fact that Git changes the hashes will make the conflict reappear the second time you cherry-pick.