[jhoechtl]

I am not saying git is flawless but most complaints seem to be about the "porcelain" and not its inherent design. I think Git tremendously outgrow the original audience so a larger proportion of people complain.

Complaining about the porcelain is like complaining about vim's complexity: It takes some time to master but ultimately it is rewarding.

[pmeunier]

Context: I'm the main author of Pijul, and also a big fan of Git.

This sounds like a potential strawman argument to me, so let's be clear about the complaints you've heard, and my complaints against Git (which, again, I love and admire as the most elegant design I've ever seen for a tool like that).

Mine are not at all in the porcelain, but in the plumbing. My specific complaints are:

- Merges in Git don't have enough information to do the job, and the optimisation problem it tries to solve is underspecified, regardless of which merge algorithm it uses (3-way merge or other): sometimes, there are multiple solutions, and Git ends up choosing a random one. This breaks a fundamental expectation on merges called associativity.

- Solving conflicts doesn't really solve them, it just records a version without the conflict. This can waste engineering time in two ways: either because you need to think deeply about the tool when solving the conflict (and use `git rerere`), or you need to follow a strict workflow, making your work methodology serve the tool rather than the opposite.

- Similarly, rebasing is operational transform. It works most of the time, but not always, and is quite clunky and hackish. Pijul fixes that by using a datastructure that happens to be a CRDT for that part.

In my opinion, all the porcelain issues and the proliferation of unintelligible commands comes from these basic shortcomings in the plumbing.

[woolion]

I don't think GP was trying to make a strawman, for me DCVS is a solved problem thanks to git, and all arguments I ever heard were basically people not wanting to put any effort into it and then pretending this is because 'git is too hard'.

These are pretty advanced issues which are worth solving, so I find these to be beautiful motivation. But I suspect most people are not aware some projects are trying to fix these issues. It's a bit as if you are trying to solve some of Haskell flaw while most people are still stuck doing javascript...

The homepage is giving this motivation but it was not clear from the linked page, which is the point where the discussion in this thread is starting from. Congrats on the milestone and good luck!

[pmeunier]

> I don't think GP was trying to make a strawman

Potential doesn't mean intentional! Sometimes just a lack of precision causes one to argue against a point that was never made (such as "porcelain is the problem").

[masklinn]

IME/IMO, one of the big piles of crap in Git’s porcelain is that gitrevisions(7) is absolutely terrible (and, of course that git diff then proceeds to do something which looks the same but behaves completely differently).

Does pijul have something better for navigating and working with sets of changes? For reference, though I didn’t get to use them that much mercurial’s revsets were a pleasure, mixing readability, expressivity, and flexibility (modularity).

[masklinn]

> Complaining about the porcelain is like complaining about vim's complexity: It takes some time to master but ultimately it is rewarding.

It really really is not. All it is is a hurdle you get used to in your way towards getting work done.

Git’s porcelain is at best a beating whose reward is more beatings. I could count the numbers of times git’s porcelain has delighted me on two hands even if both had been cut off and burned to ashes.

[user-the-name]

Learning to master something that is complicated for no reason is not rewarding, it is a massive waste of time and effort, and only feels like an ongoing drain.

[zegl]

> I am not saying git is flawless but most complaints seem to be about the "porcelain" and not its inherent design.

This my line of thinking as well.

Git has a great low-level API that's very powerful and flexible, but the porcelain and the way that we use the remotes (the Hub's and Lab's) could be a lot better. The current way is neither intuitive nor shaped after how most developers want to work (it's hard for beginners to get started, collaborate, and share ideas, etc).