Oh shit, git (2016) • Hacker News Board

Re: Oh shit, git (2016)

#271

Post by jzoch » Wed, May 15, 2019, 3:55 PM UTC

andrewla wrote: post #172

jchw wrote: post #35

Earlier quoted context omitted.

I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. That’s not all it has going for it either. Mercurial has a concept of commit stages to make history rewriting safer. It has a commit model that enables you to work on and manipulate branches of commits seamlessly, without needing named branches. It has not just a tree of commits but also each commit trac…

> I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. I think that's true if you're coming from something like Perforce or Subversion and have some notion of what the expectations are around those environments. It's much easier to translate that model into Mercurial commands. But in the end it's deceptive; git, ugly as it is, reflects the underlying data…

I've heard this repeated a lot but honestly find it very untrue. I understand git internals and watched half a dozen talks on hit but still have to Google how to split a commit in two or how to safely rebase vs merge when I'm dealing with too many conflicts in my rebases. How to accept their or my commits during a merge or rebase so I can skip conflict resolution, how to do X or Y. It's just bad UX. It's okay! I don't blame the tool but repeating "it's fine if you understand how it works" doesn't help, it perpetuates the idea that this bad UX is somehow good

Re: Oh shit, git (2016)

#272

Post by marssaxman » Wed, May 15, 2019, 5:59 PM UTC

andrewla wrote: post #172

jchw wrote: post #35

Earlier quoted context omitted.

I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. That’s not all it has going for it either. Mercurial has a concept of commit stages to make history rewriting safer. It has a commit model that enables you to work on and manipulate branches of commits seamlessly, without needing named branches. It has not just a tree of commits but also each commit trac…

> I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. I think that's true if you're coming from something like Perforce or Subversion and have some notion of what the expectations are around those environments. It's much easier to translate that model into Mercurial commands. But in the end it's deceptive; git, ugly as it is, reflects the underlying data…

It doesn't matter if you've learned git's data model or not; its use of terminology is inconsistent and confusing, and its command interface is disorganized and asymmetrical. In that way, I suppose it is very much like a "natural language", and not like the sorts of languages we are more accustomed to using when getting things done. Even if I know exactly what I want to do to the data structure git is managing, that doesn't help me find the commands I need to type to accomplish it. I have been using git for ten years now and I still have to rely on rote memorization of specific recipes in order to get anything done, which sucks because I am terrible at rote memorization.

Re: Oh shit, git (2016)

#273

Post by mehrdadn » Wed, May 15, 2019, 7:18 PM UTC

lmm wrote: post #263

mehrdadn wrote: post #253

Earlier quoted context omitted.

> Anything that's pushed to the repo is presumed good to pick up, that's what the repo is for. If it's not ready for others to pick up then why push it to the repo at all? You push... because you have 2+ repos you want to sync? Because you don't want to lose data if you mess things up locally? Because the remote repo runs tests on push that you want to run before you've finished the entire branch? Because someone els…

> You push... because you have 2+ repos you want to sync? Because you don't want to lose data if you mess things up locally? Because the remote repo runs tests on push that you want to run before you've finished the entire branch? Because someone else needs to be able to pick up your code if you get hit by a bus tomorrow? Because your boss or coworkers might need to be able to look at your code in an emergency? There…

> If it's good enough to run remote tests on, it's compiling and presumably working locally.

To you "he pushed his commit and tests got triggered" implies "his commit is compiling and working fine locally" and therefore implies "ready to build on top of"? You never push incomplete work while intending to continue it the next day... maybe on another machine? You never run across build failures on other machines when everything builds fine locally? You never see bugs that don't repro locally? You never trigger or re-trigger tests to narrow down bugs you can't repro locally but know to exist? Every single commit you push can be assumed to build on everyone's machines, pass all tests, and provide a proper foundation to branch from? And these are all true for everyone you work with too?

> You didn't explain anything!

I explained a heck of a lot?? I explained that force-push is useful on commits that you're not intending others to build on top of; I gave at least 5 common examples of why people push code despite it not being in a proper state to build on top of; I explained that rebasing on a gently-pushed commit is exactly the same as rebasing on a force-pushed commit; I explained how your teammates can force-push if you didn't somehow insist on saving the 5 seconds it would take you to communicate with them that you're going to build on top of their branch and maybe find out if you should be doing that in the first place (both of which you often should be doing anyway); I explained that if you took the few seconds to communicate then mistaken pushes would be rare and you could just resolve them by reverting or resolving commits like you normally would; I explained how git has specifically provided multiple features and documentation to support and explain both workflows because both of them have their own benefits and neither is superior... and yet somehow I "never explained anything" and "went straight from arguing about terminology to accusing me of dogmatism"?

Seriously? You don't feel even you're slightly misrepresenting things? I almost didn't even write this comment, but now I'm definitely done with this.

Re: Oh shit, git (2016)

#274

Post by dllthomas » Wed, May 15, 2019, 7:27 PM UTC

jchw wrote: post #252

dllthomas wrote: post #248

Earlier quoted context omitted.

I guess I'm arguing that UX extends beyond command names and learning curves (while definitely incorporating those things). I'm on-board with the notion that there are aspects of git's UX that are terrible. But as a user, if your experience was awful, you would not love the software.

I mean, once you’ve gotten used to a given interface over years and years of practice, it’s obviously going to be a better experience for you. I practically have Git muscle memory at this point, to the point where I frequently type Git commands in Mercurial repositories. I guess the real point is, just because we, who are experienced with Git, now have a good experience with Git, does that mean Git UX is good? I’d ar…

"It takes more time to learn" is an important aspect of UX, and as I've said there are clearly ways in which the git UX can be improved.

But having said that, I really feel like the experience of expert users also matters and is often overlooked in discussions of UX. And I just don't think people love software when their experience using it is terrible.

Re: Oh shit, git (2016)

#275

Post by lmm » Wed, May 15, 2019, 9:20 PM UTC

mehrdadn wrote: post #273

lmm wrote: post #263

Earlier quoted context omitted.

> You push... because you have 2+ repos you want to sync? Because you don't want to lose data if you mess things up locally? Because the remote repo runs tests on push that you want to run before you've finished the entire branch? Because someone else needs to be able to pick up your code if you get hit by a bus tomorrow? Because your boss or coworkers might need to be able to look at your code in an emergency? There…

> If it's good enough to run remote tests on, it's compiling and presumably working locally. To you "he pushed his commit and tests got triggered" implies "his commit is compiling and working fine locally" and therefore implies "ready to build on top of"? You never push incomplete work while intending to continue it the next day... maybe on another machine? You never run across build failures on other machines when e…

> You never push incomplete work while intending to continue it the next day... maybe on another machine?

Nope. I wouldn't want to switch machines halfway through a change that left the code broken. I'd either get to a point where it was working, or just not push. (Being able to break changes down into small pieces while keeping the codebase working at all times helps, but that's a good skill to develop anyway - it makes automated bisection in the future much more effective).

> You never run across build failures on other machines when everything builds fine locally? You never see bugs that don't repro locally? You never trigger or re-trigger tests to narrow down bugs you can't repro locally but know to exist? Every single commit you push can be assumed to build on everyone's machines, pass all tests, and provide a proper foundation to branch from? And these are all true for everyone you work with too?

Occasionally you'll hit a transient or machine-dependent bug, sure. (That can happen in master too, though it's less of a risk). But again, it's not a big deal when that happens. If you discover a bug in someone's branch then that is a situation that's worth interrupting them to talk about. You coordinate, they fix it and you pull their branch again - or you fix it and they pull your branch. Most likely you need to communicate and collaborate on the fix in any case, since you know what the bug is while they know what their changes were.

There's a cost and a risk associated with working with code that hasn't yet passed all of the master gates. But there's also a cost and a risk to working on a particular code area without seeing your coworker's changes in that area, even if they haven't gone into master yet. Most of the time the tradeoff works in favour of pulling their branch, IME.

Re: Oh shit, git (2016)

#276

Post by pmeunier » Fri, May 17, 2019, 10:02 PM UTC

dahart wrote: post #175

batisteo wrote: post #80

Earlier quoted context omitted.

> Git is pretty nice, but I'm sure there is something much better waiting to he invented. It is indeed being invented. It’s called Pijul: http://pijul.org/ This tool is based on strong mathematical theory of patches, instead of snapshot/commit-based. It seems simpler to reason with, but we’d have to unlearn a lot from Git. It’s not suitable for big projects yet, but it’s already used by Pijul itself and other Rust co…

> This tool is based on strong mathematical theory of patches Is this a good thing? What practical problems does a strong mathematical theory of patches solve that git doesn’t? And what’s the difference between a commit and a patch? Aren’t git commits stored as patches? I’m a math lover, but my gut reaction to that idea is that it sounds off-putting. I don’t mean that as a judgement or insult; I’m admitting my own as…

I'm one of the authors. Our goal is to make something much much easier to use than Git, and we're already succeeding in doing that.

The math can be completely ignored by the user, it is just a way to guarantee that the tool will always match the basic intuition of version control. For instance:

- "Associativity" is a concept of algebra, but when applied to version control, it just means the following: let's Alice makes a commit A, and Bob makes two commits B and C. If Alice pulls B, and then pulls C, associativity means that she'll get the same as pulling B and C together. Pijul is associative, but Git is not!

- "Commutativity" is also a concept of algebra, but in practice in version control, it means that you don't have to think about feature branches. In Pijul, two patches that you could produce on different branches are "independent" anyway. Applying them in any order will always yield the same result, so you can push any of them, no matter the order in which you made them. This property means that "rebasing" becomes much simpler: it's just the action of applying and unapplying patches. Also, cherry-picking becomes the default, you don't even have to think about it.

- "Inverses": in Pijul, all patches have inverses. Sure, it sounds like `git revert`, except that `git revert` can sometimes screw things up very badly (if you `git revert` a merge commit, for instance).

Also, in Pijul, conflicts are the normal state, so you don't need anything like `git rerere`, and two users with the same patches (even in different orders) will always see the same conflicts. If you have a patch solving a conflict between two other patches, then the conflict is solved forever, and doesn't "come back".

As a conclusion, I'd say Git might be too technical for a normal programmer (which is why we have giant threads like this one on HN), but Pijul is the exact opposite.

It is as powerful as Git, but beginner-friendly, infinitely faster to learn, and more flexible. Since there can be no "bad merge", you don't have to think about your version control system anymore, and can focus on your work.

That said, there are still a few problems:

- it's not yet as efficient as Git for storage, but we're working on it. We just released the first full implementation a few weeks ago.

- it will never be as good as Git for detecting file moves, because Git is happy with a soup of blobs, whereas Pijul needs more structure (but OTOH that extra structure makes Pijul much better at "blame").

Re: Oh shit, git (2016)

#277

Post by pmeunier » Fri, May 17, 2019, 10:04 PM UTC

dahart wrote: post #175

batisteo wrote: post #80

Earlier quoted context omitted.

> Git is pretty nice, but I'm sure there is something much better waiting to he invented. It is indeed being invented. It’s called Pijul: http://pijul.org/ This tool is based on strong mathematical theory of patches, instead of snapshot/commit-based. It seems simpler to reason with, but we’d have to unlearn a lot from Git. It’s not suitable for big projects yet, but it’s already used by Pijul itself and other Rust co…

> This tool is based on strong mathematical theory of patches Is this a good thing? What practical problems does a strong mathematical theory of patches solve that git doesn’t? And what’s the difference between a commit and a patch? Aren’t git commits stored as patches? I’m a math lover, but my gut reaction to that idea is that it sounds off-putting. I don’t mean that as a judgement or insult; I’m admitting my own as…

> The FAQ even says, “Pijul is trivial for whoever knows category theory.” Is that question really asked frequently? Words like that might convince me to never try it. ;)

There have been a few blog posts after we first announced it saying "Oh, it's just category theory, so I could rediscover it independently in Haskell in just a few hours".

Re: Oh shit, git (2016)

#278

Post by pmeunier » Fri, May 17, 2019, 10:06 PM UTC

stevekemp wrote: post #125

batisteo wrote: post #80

Earlier quoted context omitted.

> Git is pretty nice, but I'm sure there is something much better waiting to he invented. It is indeed being invented. It’s called Pijul: http://pijul.org/ This tool is based on strong mathematical theory of patches, instead of snapshot/commit-based. It seems simpler to reason with, but we’d have to unlearn a lot from Git. It’s not suitable for big projects yet, but it’s already used by Pijul itself and other Rust co…

I had a sudden flashback to using darcs, which was also based upon patches instead of commits. darcs was nice, up until you hit the exponential merge problem.

I'm one of the authors. Pijul is indeed heavily inspired by Darcs, but we solved that problem completely.

All our algorithms are in time at most log of the size of history, which is a double-exponential improvement over Darcs' worst case complexity.

Re: Oh shit, git (2016)

#279

Post by dahart » Sat, May 18, 2019, 3:19 PM UTC

pmeunier wrote: post #276

dahart wrote: post #175

Earlier quoted context omitted.

> This tool is based on strong mathematical theory of patches Is this a good thing? What practical problems does a strong mathematical theory of patches solve that git doesn’t? And what’s the difference between a commit and a patch? Aren’t git commits stored as patches? I’m a math lover, but my gut reaction to that idea is that it sounds off-putting. I don’t mean that as a judgement or insult; I’m admitting my own as…

I'm one of the authors. Our goal is to make something much much easier to use than Git, and we're already succeeding in doing that. The math can be completely ignored by the user, it is just a way to guarantee that the tool will always match the basic intuition of version control. For instance: - "Associativity" is a concept of algebra, but when applied to version control, it just means the following: let's Alice mak…

Thanks for the reply and explanation. You’re convincing me to at least try it.

I want to understand first-hand by using Pijul what you mean by not needing rerere and having no such thing as a bad merge. Do you mean it’s not possible to make merge mistakes, or just that the default choices made by the version control system are never wrong? The only times I’ve ever needed rerere are when I made mistakes rebasing or resolving merge conflict, and I had to roll back and do a bunch of them again. In that case, I chose to manually undo my merge, so rerere is just saving time from having to repeat all of my decisions when only a few were wrong.

I like the idea of Pijul being better at blame. Of course the main thing that needs to happen is tooling. Git’s blame has been fine but the UI for it stinks. This is maybe the feature I miss from Perforce the most; the blame UI in P4V is superlative compared to git.

Re: Oh shit, git (2016)

#280

Post by pmeunier » Sat, May 18, 2019, 11:57 PM UTC

dahart wrote: post #279

pmeunier wrote: post #276

Earlier quoted context omitted.

I'm one of the authors. Our goal is to make something much much easier to use than Git, and we're already succeeding in doing that. The math can be completely ignored by the user, it is just a way to guarantee that the tool will always match the basic intuition of version control. For instance: - "Associativity" is a concept of algebra, but when applied to version control, it just means the following: let's Alice mak…

Thanks for the reply and explanation. You’re convincing me to at least try it. I want to understand first-hand by using Pijul what you mean by not needing rerere and having no such thing as a bad merge. Do you mean it’s not possible to make merge mistakes, or just that the default choices made by the version control system are never wrong? The only times I’ve ever needed rerere are when I made mistakes rebasing or re…

It's indeed not possible to make merge mistakes in Pijul, in the sense that the order between lines is always preserved: if line A comes before B in one repository, A will be before B in all repositories that have these two lines.

Moreover, merge is associative, which is the intuitive idea of a "good merge", in the sense that merging your patches one by one is the same as merging them all at once (this is false in Git).

In Pijul you can't "make mistakes rebasing". A repository is a set of patches (set as in maths), you can add patches or remove patches from the set, and that's about it. Two repositories with the same set of patches (possibly applied in different orders) are totally equivalent (in particular they have the same file contents).

So, rebasing in this case would be just the operation of adding some patches and removing others, and hence you can't make mistakes doing that, because there is no manual merge operation needed (of course you still need to solve your conflicts).