81–90 of 154 posts
This is why I'm really excited about the potential of Pijul. In pijul, commits are diffs, and you avoid all of the rebase/cherry-picking craziness of Git. Still alpha software, so tons of roughs edges, but the potential is incredible. I think it'll be similar to the centralized -> distributed revolution that git ushered in.
Git is the leakiest abstraction in the history of abstractions. Diffs are a "natural" object for version control yet got doesn't actually use them and as we can see in this article, multiple git commands leak this implementation detail.
At a lower layer than that (the pack files) it does use binary diffs to store similar objects as deltas to save on disk space.
TL;DR diffs play an important part in git's machinery at different levels of abstraction. They just aren't part of how it represents its domain model.
A fascinating bit of history is that the reason for this data structure was to explicitly distance git from BitKeeper. BitKeeper was used by many kernel developers, until one of them (the co-inventor of rsync, unsurprisingly) reverse-engineered its protocol, leading its proprietary owner to end its offer of a free license to Linus Torvalds and other developers. While searching for a replacement, the Linux community s…
If all I had to go on was Bryan O'Sullivan's email, I'd be tempted to draw some unflattering conclusions about McVoy's conduct.
Commits are not 'just' the snapshots as the ancestor references and metadata matter. I for one think the title is a distinction without a difference (if you already accept that a git hash represents both the current set of exact files and ancestors) but the content is well presented for anyone.
This is why I'm really excited about the potential of Pijul. In pijul, commits are diffs, and you avoid all of the rebase/cherry-picking craziness of Git. Still alpha software, so tons of roughs edges, but the potential is incredible. I think it'll be similar to the centralized -> distributed revolution that git ushered in.
There's nothing intrinsically superior about storing commits as diffs - subversion stores its commits as diffs (or at least, it did a decade or so ago,) and I haven't heard anyone enthusing about svn in a long time.
Have you ever had to laboriously cherry-pick a series of commits solving some bug between branches (e.g., from stable to dev or vice-versa)? It's painful, and then later on you get conflicts because when you cherry-pick, git doesn't "understand" what's happening. Pijul solves that.
At a fundamental level, imagine I'm editing two files A and B, that have nothing to do with each other. Because git's level of dependency is the entire repo, if I switch back and forth between editing A and B, git inserts a series of arbitrary and not-actually-real dependencies between those edits. Then, as a consequence, there's no easy way for me to decide, say, I would like to merge my changes to A somewhere, but not my changes to B.
Or how about the entire controversy(/complexity) of whether to rebase or merge when pulling? The choice is an artifact of git's model, really a question of "in which way would we like git to represent some not-real constraints". This difficulty doesn't exist in Pijul, where dependencies are more fine-grained and real.
Another pain point you may have hit w/ git is when you do a merge, but somehow actually the changes were not included; this usually happens as a result of confusion regarding a conflict. Then you have to do painful repo surgery to try to convince git to actually include the changes you want.
In general large conflicts are quite painful in git: for the duration of the conflict, you are in a special state, and cannot commit. In pijul, conflicts are a first-class state of the repo, so you can iteratively work towards resolving your conflicts, using all of the normal VC tools to checkpoint along the way.
Disclaimer: I've only played with Pijul, not used it in anger. I definitely see a lot of potential though.
A fascinating bit of history is that the reason for this data structure was to explicitly distance git from BitKeeper. BitKeeper was used by many kernel developers, until one of them (the co-inventor of rsync, unsurprisingly) reverse-engineered its protocol, leading its proprietary owner to end its offer of a free license to Linus Torvalds and other developers. While searching for a replacement, the Linux community s…
I forget - was there another side to the story that made McVoy's actions seem more reasonable? If all I had to go on was Bryan O'Sullivan's email, I'd be tempted to draw some unflattering conclusions about McVoy's conduct.
That said, in his defense, causing the creation of multiple open-source competitors to one’s moneymaker can be stressful.
Earlier quoted context omitted.
I wonder if this is why Mercurial is so much simpler and easier to understand than Git -- precisely because Git was forced to adopt a more "out there" approach. Personally I'm sad Git won out over Mercurial -- the latter is a much better technology from my experience.
> Mercurial is so much simpler and easier to understand than Git I think it must just be a mindset thing. The way git works makes perfect sense to me and I don't know why you would do it any other way. But git was already gaining significant traction when I started using version control. I can see how having built your mental models around previous version control systems and then trying to superimpose that on git wo…
Earlier quoted context omitted.
I wonder if this is why Mercurial is so much simpler and easier to understand than Git -- precisely because Git was forced to adopt a more "out there" approach. Personally I'm sad Git won out over Mercurial -- the latter is a much better technology from my experience.
> Mercurial is so much simpler and easier to understand than Git I think it must just be a mindset thing. The way git works makes perfect sense to me and I don't know why you would do it any other way. But git was already gaining significant traction when I started using version control. I can see how having built your mental models around previous version control systems and then trying to superimpose that on git wo…
Earlier quoted context omitted.
Are you sure about that? See "Why a new version control system?" at https://pijul.org/faq/ and the linked "badmerge" example: https://tahoe-lafs.org/~zooko/badmerge/simple.html
If a project wants to hold up a bad merge as an example why they are better. They need to do better than just a list of letters. They need an actual example of real code.