Pijul: a distributed version control system, written in Rust (2019) • Hacker News Board

Re: Pijul: a distributed version control system, written in Rust (2019)

#121

Post by _fbpt » Mon, Jan 13, 2020, 1:44 PM UTC

lillecarl wrote: post #111

_fbpt wrote: post #90

Earlier quoted context omitted.

About half a year ago, I tried to merge two forks of a single program which had diverged by several years. I tried a Git merge, got halfway through conflict resolution, stashed my current changes and reset my repository, and could not reapply my partial resolution. (The proper approach would've been to manually run `git rerere` without arguments to save the current partial resolution, but I didn't know that). I redid…

I suggest you check out git-imerge, it's a quite handy tool for making complex/big merges simple.

https://github.com/mhagger/git-imerge

> Reduce the pain of resolving merge conflicts to its unavoidable minimum, by finding and presenting the smallest possible conflicts: those between the changes introduced by one commit from each branch.

I'm not sure this would've helped in my scenario. famitracker had no public repo, and the Qt fork and 0cc-famitracker came from different Git repositories and were rooted in different subdirectories. I created a synthetic Git and Pijul history for the purpose of this merge.

But it might be helpful in other situations. I'll look into it.

> Allow a merge to be saved, tested, interrupted, published, and collaborated on while it is in progress.

This does seem useful.

Re: Pijul: a distributed version control system, written in Rust (2019)

#122

Post by core-questions » Mon, Jan 13, 2020, 7:29 PM UTC

gnufx wrote: post #117

core-questions wrote: post #22

Earlier quoted context omitted.

The problem with Darcs, which I've seen in use, is that the tooling around it is atrocious. Compared to something like Bitbucket or GHE, it's a huge pain for a bigger team, and requires a very oldschool workflow. There's a Jenkins plugin that barely works, you have to build your own new version because distro packages are old, etc. Not sure whether there's any actual advantage at all.

I'd hope my revision control didn't need a lot of tooling, personally. I have Emacs darcsum and vc-darcs, and Trac integration, with hooks to use on commits etc. I guess darcsden (hub.darcs.net) is similar to pijul nest. There doesn't seem to be any real problem integrating it with things (that don't insist on a CVS-ish model) if people want to do it, it's just that few do, unfortunately. I haven't had time to see ho…

> I don't know what GHE is, but making me interact with github or bitbucket isn't a good way to encourage me to contribute to projects

GHE is Github Enterprise. Most software development teams use that or Bitbucket or Gitlab, because there's a ton of value in the visual interface, the approach to code reviews, approvals, etc. that is hard to recreate in any other form.

You still push Git patches to it the same way as you would to any other Git repo.

Re: Pijul: a distributed version control system, written in Rust (2019)

#123

Post by afiori » Sun, Jan 19, 2020, 9:27 PM UTC

dan-robertson wrote: post #114

macintux wrote: post #106

Earlier quoted context omitted.

CRDTs have to tackle this sort of problem as well.

Right. And a CRDT for a set you can add and remove from is either hard or weird for this reason. Also I think you don’t actually want your repo to be a CRDT because a CRDT resolves all conflicts and that would mean merge conflicts get resolved in an arbitrary way (leading to unexpected results and bad code). Maybe you could say that merge conflicts don’t count as conflicts in the CRDT sense of the word but that just…

I don't know how good of an idea CRDT would be here, but from the pijul perspective the CRDT layer should not possibly create a conflict, in the same way a `git fetch` should never cause a conflict (assuming well behaved hashes).

The CRDT layer would produce a set of patches in an unmergeable state and then pijul would have to fix it; just like git.

Re: Pijul: a distributed version control system, written in Rust (2019)

#124

Post by afiori » Sun, Jan 19, 2020, 9:33 PM UTC

rumanator wrote: post #102

pmeunier wrote: post #52

Earlier quoted context omitted.

> The criticism directed by the Pijul guys at git cherry-pick is actually not a problem at all. Maybe, maybe not, but it comes with actual arguments, whereas that comment doesn't.

There is a clear argument that you chose to ignore: cherry-picks are patently not a problem in Git, and the only problematic aspect is how some git users might create their own personal problems by developing misinformed workflows while ignoring any information on best practices. If you try to reinvent the wheel on your own, ignore any advice or info, and end up with a badly shaped polygonal thing then you simply can…

A lot of the criticism git receive is about the stance that there is the git way and the wrong way.

We all are super sure that git has extremely efficient workflows available; it is just that maybe many people do not like them.

Git does not try to be a tool for everyone; it is very opinionated on how to best use it; this obviously leaves space for less opinionated tools or even differently opinionated tools to shine under specific use cases/scenario

Re: Pijul: a distributed version control system, written in Rust (2019)

#125

Post by jupp0r » Tue, Jan 21, 2020, 4:42 AM UTC

echo-oddly wrote: post #78

jupp0r wrote: post #73

Earlier quoted context omitted.

If A, B and C are patches, you are applying C last on the left side and A last on the right.

You are wrong. Yes, on the left side B is applied to A, then C is applied to the result (AB). However, on the right side, C is applied to B, then the result (BC) is applied to A. A is still the left most patch in both cases. BC could depend on (the output context of) A so it wouldn't make sense to apply A to BC! BC is applied to A. A(BC)

So you are saying that applying patches is not commutative? I was assuming A(BC) == (BC)A. What makes you think that the result should be different depending on the order?