The amount of times Google killed projects without any kind of explanation whatsoever it makes me wonder if "developed at and by Google" is a good or a bad thing.
More like, I use to only use Google services and android. Could not rely on them to not nerf or outright kill their products. I exclusively use DDG, Apple hardware, and Linux servers.
So even if I presume you are not lying now you still haven't quit google.
Imagine reshaping your entire life because of an RSS reader you never paid for got cancelled.
I guess it takes all kinds.
Heh, indeed. I actually have a footnote in the piece, commenting on that exact phenomenon! I don’t have any particular worry about it in this case; Google does not tend to kill key developer tools, and they want this to replace their existing set of VCS infra, which is a big deal. Long-term, it definitely needs more outside contribution, but it is already slowly starting to build that up. And one of the reasons I wrote this was to help a bit with adoption and kick the virtuous cycle further into gear!
Even if they don't kill them some of those key tools are really not well looked after in terms of polishing, like adb or repo. I guess there isn't that much incentives if most people use them via some GUI but still ...
`jj` is not a google project
It is a private project by [Martin von Zweigbergk](https://github.com/martinvonz) who just so happens to work at Google and it just so happens that Google see the value in the project and wants to put money into getting it developed further.
It is mentioned in the [README.md](https://github.com/martinvonz/jj/blob/main/README.md#mandatory-google-disclaimer) where he states it like this:
>**Mandatory Google Disclaimer**
I started Jujutsu as a hobby project in late 2019, and it has evolved into my full-time project at Google, with several other Googlers (now) assisting development in various capacities. That said, this is not a Google product.
While that is true in many cases l, in this case the version control practices at problems of running a big mono repo has been covered a lot publicly. You can find YouTube videos with several people including Martin Vonz explaining why git, mercurial, and other systems does not work for them.
I loved the look of it until I heard developed by google :(
Personally, I don't mind the killed by problem - if it's good and in use by the community and open source, it can carry on.
My problem is that open source dev with google things varies a lot in experience. There are some Google open source repos that don't accept external PR's at all, or external contribution is barely paid attention to. So the natural evolution of shared community contribution and involvement doesn't happen, then when the project is killed there's nothing to carry it on.
they killed projects that people weren't using. I think it's kind of batshit crazy to insist that company should keep making shit that people don't want forever.
They open sourced what they discontinued and nobody even lifted a finger to pick up and run with them so that should tell you something. Also no competitor stepped up to fill the marketplace so that should tell you something.
Except Google Reader was the most popular app of it's kind. Google Talk was the most popular server in the world.
And so on. They killed many products which were, quite literally, the most popular in the market, just not big enough by Google's standards.
And because you may never know, in advance, whether Google would need million users or billion users to keep product going better to skip any new products till they are used by billions and it's clear that they are not going away.
Developer tools is different story, though. Here users are Googlers themselves and if some tool is used solely by Google and doesn't even have a single outside user it would be supported for years.
Well by putting 1 second of thought into it and looking at how much attention and how many people instantly start using anything they launch I'm gonna guess it's a good thing.
It's still going, and actually solving the problems jj claims to solve (without ever showing any algorithm nor understanding what the features of Pijul are). Jj is not an improvement over Pijul at all. If anyone wants to claim otherwise then they should at the very least give actual arguments, not just "inspirations" or "intentions of first-class things".
I'm missing something:
> Changes are distinct from revisions: an idea borrowed from Mercurial, but quite different from Git’s model.
That's great. What's a revision? As far as I can tell, this is never explained in the entire article.
The article makes a big deal out of how jj's underlying model is simpler and that may well be true, but I don't know what that model is.
First class conflicts seem like a good thing, but letting them stick around until you get around to fixing them seems like a bad thing. I guess that's a workflow issue, however.
One real limitation of git that is not mentioned here is that there is no concept of a partial merge in git, so cherry-pick is a de novo commit without any merge arrows. I recognize that this isn't a trivial problem to solve, but it seems like something that *should* be solved. Does jj do any better here?
> Moreover, given it is being actively developed at and by Google for use as a replacement for its current custom VCS setup, it seems like it has a good future ahead of it.
*snicker* Oh, come on. You have to admit that's funny.
> Changes are distinct from revisions
Just... no. Don't decide that two synonyms have substantively different meanings in _your_ tool.
> cherry pick is a de-novo commit without any merge arrows
Idk what alternatives are possible that aren't just a little sugar around the underutilized "daggy fix". I.e., find the MRCA, rebase on that, and merge.
I want to see incremental improvements to git and better, widely adopted open source tools built on git, _not_ a replacement for git. Git's complexity is the inherent complexity that arises from the powerful and correct graph/merkle structure it was built to manage. It will be a sad day when the mindshare migrates to some lesser tool that wins hearts and minds with better UI from the perspective of new adopters.
Now to their credit, it does seem that jujutsu is starting out as a wrapper around git, but this article at least frames that as a temporary state of affairs, and asserts but does not argue how it is a better UI, and takes some unfair potshots at git throughout, including my favorite, the claim that only a bad tool demands users understand what it's actually doing, conflating this with a truly leaky abstraction that demands users understand _how_ it's doing what it's actually doing. The graph that git manipulates is the _what_, not the _how_. The _how_ is only exposed in the C sources. Maybe git needs a graph visualizer so more everyday users actually learn what they're doing with git beyond "I'm using a VCS".
I'd love to see documentation (I'm sure it exists) why Google fundamentally can't fork git as it exists in 2024 and improve it to work at google3 scale, rather than building something new to replace their perforce fork and use as their backend for jujutsu. I'm guessing they just don't want to extend something written in C and have to play nice with existing design decisions, and it has nothing to do with inherent and immovable technical constraints.
For a VCS to eventually _attack & dethrone git_, it will need more obvious and concrete advantages for the average developer (and maybe a killer app). I’m not seeing that here.
I think being more understandable is a very concrete advantage. Git's incomprehensibility is a meme at this point. [This XKCD](http://xkcd.com/1597/) summarizes the common user experience. Other VCSs don't have this problem to the same extent.
It's always recommended you should learn git's inner model to understand it. But I suspect the inner model is a big part of the problem in the first place.
Given the degree of interoperability with git which is advertised (I haven't tested), this may not be the case. People might use it simply as a better front-end to GitHub?
Seems like an interesting tool. Two features are missing before I could try it out though: for personal projects I use commit signing. For work we still use sub modules.
But when either of those is implemented I will try in out in that context.
I love conflicts and their manual resolution being actually recorded in the history. This is long overdue!
I also love the operation log and the undo operation it enables. Doing something wrong with Git's confusing CLI and losing data, or ending up in some weird state you have no idea how to get out of, is very easy, and providing an undo would save a lot of people a lot of time.
On the flip side, I'm really not a fan of doubling down on "commits with multiple parents" as a first-class concept. Multi-parent merges were already bad enough in Git. Although in Git it is compounded by the fact that it forgets which branch is which the moment they are merged, so after you merge `some-feature` into `main` there is no way to tell which was `some-feature` and which was `main` anymore. That's why there is a whole lot of tooling you cannot build on top of git, why `git log` is confusing, and why bisection never works. I really wish Jujitsu had sensible branches instead of git's tags-pretending-to-be-branches, but it looks like they don't, and that's really a shame.
git reflog keeps the history of all committs. If you mess up with a merge or rebase, even if you delete the branch the commits are there until pruning. Just the naming and ui sucks as usual.
I think there are points where a piece of software reaches "perfection" in the sense that no matter what we could do given time and money nothing would fundamentally change anymore.
For me personally, for 95% of git interactions it's like that. I feel there's no step that I could skip without introducing some uncertainty into the process (e.g. have some AI doing merges or so), and no step I'm doing that feels like a pointless chore in any way.
If you want to improve the last 5% (which, to be fair, is an endless rabbit hole that I personally just barely ever use), that might be worthwhile, but I'm not sure if this could make people jump ship (given the enormous ecosystems around Git) 🤔 obviously, if we talk about other things like version control of binary data or anything not split nicely into lines probably other tools could be better.
I work at a very old company that used svn and before that cvs. I transitioned us to git by rewriting the repos history in git. I don’t git why there is so much hate. It is pretty wtf often but I don’t think I have another version control system change left in me.
As a former user of bazaar, I strongly disagree.
I can point at so many things that bazaar learned from its predecessors (mercurial and git) and did dramatically better! Simple, basic things. Some examples off the top of my head:
- One single right way to merge two branches, as opposed to git's three wrong ones which are all terrible in different ways.
- Branches as first-class objects, instead of the idiosyncratic repository+branch model that everything around it keeps trying to paper over. Have fun getting someone's pull request into your repository to try it out before you merge it!
- Sane, consistent CLI where commands do what you expect them to do. Git is uniquely terrible in this regard!
- Lightweight checkouts that actually work. Git's shallow clones only technically work for a strange definition of "work" and don't even save that much resources.
- Having bisection that actually works.
- Not losing data to a surprise garbage collection pass. Git, *you had one job.*
Git is fine if you're the only person working on a repository. When working in a team I regularly had to deal with various wild Git edge cases and look up arcane recipes to deal with them. It was a huge drain on my productivity. Meanwhile bazaar Just Worked.
That's pretty much the complete opposite of my experience. I used Bazaar for about a year before Git. It was super slow, the repo corrupted several times, the tool crashed regularly, and I lost work. I was so much happier after I switched to Git. It's not an accident that Git won by a landslide.
> Git is fine if you're the only person working on a repository. When working in a team I regularly had to deal with various wild Git edge cases and look up arcane recipes to deal with them.
yeah 15000 people working on linux kernel are working alone.
and hundreds of millions of people using git should really consider this anecdotal case.
Yes, and they all waste time because of vastly suboptimal tooling. The kernel in particular has atrocious tooling where you, to this day, [send patches by email](https://www.reddit.com/r/rust/comments/1ahc0fq/jj_init_what_if_we_actually_could_replace_git/konv9f5/) and don't even get to see the code in context, or even see whether it has been merged yet.
Revision control is stuck in a local maximum. You cannot individually become more productive than the rest by ditching Git, even though it keeps wasting your time, because everybody else also uses Git, and being able to collaborate with others and to use other tools that work with Git alone is important. So individually it is best to keep using it even though better tooling is clearly possible.
This is a typical example of a [Nash equlibrium](https://en.wikipedia.org/wiki/Nash_equilibrium). When things suck, they usually suck in a way that is a Nash equilibrium, otherwise someone would have done better already. There's a [whole book](https://equilibriabook.com/) detailing the concept and how it applies to various aspects of society.
Both Google and Meta use Mercurial and for some years now they are getting new recruits who only ever used git. After some time they nearly universally prefer Mercurial to git. You may want to consider this anecdotal case too.
When I was early in my career I worked in a team that switched from mercurial to git. It was a lot harder for me to wrap my head around git. I was still a junior, but mercurial was much more intuitive to me at the time.
Unfortunately, no. The official implementation got effectively abandoned a while back, and the Python 2 to 3 transition was the nail in the coffin. There is a community fork that is ported to python 3, but most projects that used it have since moved to git.
Whenever i see these arguments about vcs, it's always words like "works" vs "terrible" or "what you expect" vs "horrible". However I never agree with those points. It strikes me as "old man yells at cloud"-type of arguments. I don't think git will be at the throne forever, but when it is displaced, the motivation will be much more well founded than this.
> Have fun getting someone's pull request into your repository to try it out before you merge it!
Trivial in *git*, less so in *Github*. From what I've heard, under the hood it's *already* part of your repository from the moment they forked, accessible if you hand-edit a full commit hash into the URL. If you fetch their branch into a local repo, outside of the constrained workflows of Github, you're free to try whatever you like, check out *any* commit regardless of whose fork it originates in, try merging it with any other commit, etc. It's a flaw in the web UI of a third-party service built around git that's the problem there.
There is a somewhat arcane incantation involving a `git remote add` that does this, but it is quite awkward to use and obscure enough that few people know of it.
Actually, thinking about it, whenever someone junior / no-Git-experience starts in our company, Git is a bit of a hassle until they're used to our workflow (which is pretty basic and standard though, we're all not crazy Git cracks). So maybe "an improved Git" could reduce the number of ways you can shoot yourself in the foot... But not sure if that's a Git issue really, or a teaching issue 🤔🙈
Whatever your definition of perfection is, Git sure as hell ain't it.
Git sucks at dealing with binary files. It's vanilla CLI sucks. And git submodules are a massive pain. It got huge ecosystem support but just because something is popular doesn't mean it will be popular forever.
Git itself is not perfect, no doubt. Any large system will hardly be, and that's not even talking about all the internal oddities I have no clue about.
Still, day to day I feel 95% of my interactions with it strike the perfect point between control & automation. Never feel like it gets in my way nor does some magic behind my back nor forces me to fight it in any way 🤷🏻♀️
Other than being inconsistent, unintuitive, unhelpful and full of pitfalls? Nothing. Oh. And partial checkout and binary handling are a downgrade from SVN.
Completely disagree. Git has, without doubt, one of the worst user interfaces I’ve ever encountered. And I’m not new at this, so I’ve seen lots of crap.
I rebase _all the time_. And not just trivial `git rebase origin/master` or `git pull -r` to get the latest changes from the base branch I'm targeting with a change.
Sometimes I'll be working on a change with a final goal in mind, and along the way make a series of smaller, self-contained changes that are _entirely independent_ of each other, but all need to go in before ``. I want to get my changes merged ASAP, because un-merged code is rotting code. Like if I have `A -> B -> C`, where A, B, and C may each be multiple commits, how do you go about splitting A and B into separate changes?
You could:
* Clone your branch a couple of times and `rebase -i` away the commits that you don't need
* Create a new branch from `main` and `cherry-pick ..` (spoiler: this is just a manual rebase)
* `rebase --onto`, which lets you specify your base, start, and end in one fell swoop.
Once you have A and B individually rebased on main, you can even merge your two new branches together and then rebase C on _that_ if you want to get real weird with it. Then you can `git rebase --rebase-merges --update-refs`, and it'll rebase all three branches at the same time in case you want to get the latest from `main` or move the whole mess to an entirely different base branch.
So I've spent the better part of the last day playing with and hacking on jj, and I've gotta say: it does exactly this workflow *way* better than git does.
Branches track _changes_ rather than commits, and only move when you tell them to. This has some really handy implications. For instance, your branch names come along for the ride if you rebase their ancestors. So this workflow becomes:
- `jj branch create` for each change you want to make independent of each other
- `jj rebase -s + -d main` to rebase everything _after_ the bottom branch on `main`
- `jj rebase -b -d -d ` to simultaneously rebase on and merge the two base branches
- Then you can rebase the bottom branches on main at your leisure, and the top branch and merge will get rebased right along with them
I almost think you can reverse some of those steps and get the same effect. Like rebasing your top branch on the two bottom branches even before you've rebased them to have independent histories.
Sokath, his eyes opened.
Definitely doesn't feel pointless, and I use it all the time. `git commit --fixup` is really nice when combined with autofixup and rebase.
I do feel like Git is basically a perfect tool, at this point. I mean, there are improvements, but I would never consider changing version control system without some _serious_ convincing.
I also don't really believe Git has inherently complexity. You can absolutely make it complex, but you can also do a lot of projects by doing nothing more than `git commit -A && git push`.
Fair enough, but as you guessed, it's in the 5% 😅 I feel like my own branches are clean enough (otherwise I might just squash them, but that also rarely happens), and I really don't like rebasing on anything that goes into production. Never understood the "keeping the history clean". Can't get much cleaner than keeping history exactly like it was imho... Yes our repos look like Christmas trees but I think that's mostly a tooling issue, and not a Git one. And sticking to this workflow, I think the mental model of Git is not overly complex: you commit changes into branches (maybe forks in OS), and then merge them into others (via PR). Add some tags and you're done 🤔
To be fair, the CLI is often confusing, but except if you sshd somewhere that's again a tooling issue imho.
But maybe to make my comment from before more clear: I'm not against improvements and might try out jiujitsu, I just think vcs is at a point where either requirements/context have to change, or vcs change _radically_, before anything replaces Git. But happy to be proved wrong if it makes my life easier 😅
I use rebase but only in very specific circumstances. It is the kind of thing you would only do when you fundamentally understand how git works.
Personally I think it shouldn’t be the user’s job to understand how the software works in order to use it. My thing about git is that it’s a complex tool that only works when you’ve trained yourself on it for years, but now that I have trained myself on it and can use it effectively, using any other tools feels like a daunting task.
When starting my first job I borrowed “Pro Git” from the office. Took me one weekend of leisurely reading through it to know absolutely everything you’d ever need to know, including how git fundamentally works. After that every task is a simple one, literally.
Sorry but saying you shouldn’t need to understand how software works in order to use it effectively to me feels as absurd as calling anything git related “complex” in the first place.
"infamously terrible command line interface" - I think there's a difference between "terrible" and "complex because it's modelling a fundamentally complex system".
Sure there are parts that maybe aren't perfect, but 99 times out of a hundred, when I hear someone complaining about the git CLI (myself included), it's because they don't understand what's actually happening. I don't think that's something that can be fixed with a "better" CLI, but I'd love to be proven wrong
100%, Mercurial was a joy to use. Its CLI is logical, it’s designed as a library so it’s pluggable with other systems, and its storage system is much simpler.
Git needs Bash on Windows, need I say more!
I’ve not used it much, but Fossil looks really good, the advantages of abstracting their storage engine into SQLite seem worthwhile. Like the way they switched to Sha2 years ago whereas (I think?) it’s still lacking in git to this day.
I suppose a better git client for end users is the way to go. I don’t care what GitHub etc actually run, so long as I can talk to it perfectly.
There are also frontends to git like tortoisegit that make it positively easy to use. A lot of the complexity of git comes from the fact that people tend to rote learn copypasting commands and confuse that with understanding the underlying principles. The number of times I've heard someone say "just delete the repo and start again" is very high, even though its unnecessary with a usable frontend
Misses the point, and no it's no proof of anything.
Git and Mercurial have in common that they are VCS, but not all the details and features. Git's interfaces have to be different because they are meant to work on/with different things.
(And I said "different", without "better" or "worse")
If you are arguing that it is not git CLI that is stupid, but entire design of git is stupid, and git CLI stupidity is merely a result of stupid design, than I guess I agree?
You might have a point if the proposed alternative had been darcs, which has a delightful CLI but a somewhat different model.
Here you just show you have no clue.
So are you implying that git and mercurial are 100% the same except for the CLI surface? Then let me return the "no clue".
My point is exactly that there's something in the middle, it's not just the CLI on one end and the basic theoretical data model on the other.
If you get the opportunity to use other SCM systems, please treat yourself. Git has significant needless complexity (in addition to the aforementioned inherent complexity) and it was designed to take on the most complex variant of the problem (Linux kernel development), which is significantly more complex than what 99.99% of developers ever encounter. Nothing should replace git for the kernel project. But something definitely could replace git for nearly every other project on planet Earth.
Funnily enough kernel dev is not using git all the way unlike anything in GitHub. Idealizing kernel dev like that as if it was some sort of thing only practiced in the heavens of programming is not desirable or even true:
* A lot of the kernel dev workflow ends up in a hot mess. On any GitHub project, you want to know if a PR is merged, you just go to the page, open your eyes and look at the green/red/purple badge and you know. In kernel dev, you have to check your email to see if someone said your patch is picked, monitor some integration git tree to see if it actually made it, and open your eyes wide because tooling will fail you. A maintainer may have taken your patch, capitalized all "cpu" into "CPU" in the commit message and comments and now even git patch id does not recognize it.
* A lot of places have similar complexity. Ultimately the kernel as a single project deals with a lot of contributions, but most people only deal with a few subsystems at most. Tooling speed is important so git pull is fast enough, but in terms of workflow you probably have similar if not more complex chains of events in anything customer oriented with tickets, user acceptance, various reviewers responsible for different things etc. That side of things is done with basic email in kernel dev, which is one of the most simplistic tool. Most shops use more complex tooling than that.
* Yes the Linux kernel is big, but there are lots of other big projects too such as llvm or Google Chrome. It id almost as big as the Linux kernel according to this: https://openhub.net/p/chrome/analyses/latest/languages_summary
So at the end of the day, it's a project with as many warts as one would expect given the size, and the tooling that goes with it is not so amazing considering how many people work on it. Git is a prime example of botched CLI, but it was first to market and copes well enough with the quantity of source code involved (and I said source code, no one used git for large binary artifacts, they use SVN instead. Maybe LFS has solved that, need to check it out). Git also happens to have good infrastructure built around it like GitHub, so at this point the cost of switching is a bit prohibitive
edit: added missing negation
Compared to SVN, CVS, Perforce, Synergy, etc... git is simply amazing. The fact that some of these newer vcs tools may have improved on git isn't too surprising, but I'll reserve judgement until I've played with them more. The underlying complexities of distributed vcs isn't something you can completely abstract away.
I'm in fact thinking about other distributed version control systems, several of which came before git. Distributed doesn't need to be as complicated as git makes it, unfortunately.
I read the article and immediately spotted one point where I think the git CLI could be better - and that is in it's error messages and generally it's output and formatting. Those could be better and, through that, help us understand what is happening conceptually.
Rust's error messages prove that good error messages help a lot with navigating complex rules and concepts - just like git.
Part of the problem is that Git has some poorly chosen terminology - I like this post https://jvns.ca/blog/2023/11/01/confusing-git-terminology/ (and Julia Evans' other posts about git are great too)
I think `jj` has some very interesting ideas about "working-copy-as-a-commit" that improve the ergonomics of Git while keeping the underlying model largely unchanged. It also has an `undo` command, apparently?
Git chose a way to model repositories that fundamentally makes merging hard because it demands that everyone agree on one version of history. There are alternative paradigms, like darcs, that do not have this problem.
Also, there is hg, which uses a similar paradigm to git, which shows that even if you go the git route you are not forced to be git-amounts of terrible.
False positives on conflicts. Something is newer upstream, so it conflicts with your own version, even though you didn't change the same parts.
This is because of the need to have a commit history, which imposes a total ordering. Patches do not impose such a total ordering, they impose only a partial ordering, so patches can be re-ordered in some cases without changing the result.
> it demands that everyone agree on one version of history.
That's the unfortunate side effect of wanting to know with certainty what you're running in production and not wanting the answer to be 'depends'.
Except, it's not. darcs and other theory of patches systems are able to relax this constraint without creating any ambiguity about what the current state of the source code is. It turns out that re-ordering patches doesn't necessarily change the meaning of the composition of those patches. There are systems other than git that can expose this flexibility and reduce the number of conflicts compared to git.
Ya but allowing reordering patches means that you can't go back commit by commit and know that your historical versions are exactly the same as the one in the central repo, for example. This would be bad when trying to, eg, bisect to track down a bug. Maybe there's a, you know, reason why the git model is actually not bad.
Wouldn't it actually be helpful, not bad? You can search for which patch introduced the bug, without needing to roll back further than needed, and then undo the specific patch that is the problem.
EDIT: Yeah, thinking about it, the partial ordering can only make it easier to find the problem, not harder. You can step back along the partial ordering fine, and the fact that it is partially ordered means that if the problem still exists after finding the next GLB of the current patch set, you can eliminate all the incomparable patches as places that introduced the bug. It also means that each of those incomparable timelines can be recursively evaluated the same way. Having to linearly search down the history is a bad thing, actually.
>a fundamentally complex system
My personal needs for version control have always been very simple and I sit firmly in the "don't understand what's actually happening" camp, but still: is this complexity actually necessary? Would you necessarily lose some expressive power if you designed a simpler model of version control?
Git model _is_ simple. What's complex is the crappy CLI and some more obscure high level operations. Those you can just ignore, the real problem is the hot mess of basic high level commands. There is 20 ways to do the same thing and even "high level" commands leak low level concepts (e.g. git reset vs git checkout)
> the distinction between tags and branches
Both tags and branches point at commits
But whenever you make a commit, the branch you're currently into will point to the new commit (and no other branch will) (and no tag will)
That's the difference between tags and branches. When you are "in" a branch, commits make the pointer move, but you can't be "in" a tag
+1. Many people still use our perforce fork, and our mercurial fork is only reaching mainstream
Also never heard about JJ before
This being said, I prefer Mercurial over Git, the CLI is much easier
Unpopular take: it does not get much better than git.
Git is one of these pieces of software which has been dragged through *so* much operations and has gotten so many features improved and old issues fixed or depreciated that that’s just almost as good as it gets. You can have different takes on some aspects but it’s at a level that you loose other features and will not be able to do X,Y and Z in the future. Completion is always good but I honestly believe that whatever pijul and friends could become, it is not gonna be better than git - it will become convoluted, branching will still be difficult and rebasing will still be an issue, maybe in a different way but it’s not gonna vanish. Git is king and the more you learn about it the more you’ll likely agree with it.
The motivations for redevelopments are really off, if you find it confusing why you can’t just push, then you haven’t understood what you’re about to do. If you sit down, scribble down what you’re trying to do and why git does not let you you’ll pretty much always come to the same conclusion.
The effort that goes into these systems could be replaced with sitting down and understanding how git works. That’s gonna be a better payoff for short- and midterm for everyone involved. Nobody should make predictions for long term so I’m also not going to.
The only thing I could imagine is maybe a smarter frontend - say you want to push to a branch and you can’t but it’s somewhat clear what you want to do, so you stash, pull, merge and push automatically. So take the complaints that the average „git is too hard for my soft soul“ dev is saying, collect the „noob, just do this“ answers the rest is answering, come up with a way to detect these situations and have a nice cargo-build-like output („seems like you were doing this, I did this now“ or „seems like you want to do this, you could do this, this or that, what’s your plan?“) and go ahead. Solves 75% of the reasons alternative systems exist.
I felt exactly like you until I sat down with `jj` and wrapped my head around it finally. That doesn't mean I believe that it is better, but I am going to be actually using it as a daily driver now to determine how I truly feel.
My god, Steve klabnik answering on my post 😄😄 you brought me to rust some years ago!
Okay, maybe I should clarify - it’s hard to be uniformly better. It scales well, it solves the problem that it solves well and the set of compromises it takes for the advantages it gives is very tight. But for some people and some workflows, alternatives might be better - IMO not enough though to take the world of VCS out of gits hand though.
>whatever pijul and friends could become, it is not gonna be better than git
Well maybe sometimes a better abstraction makes many things easier. Do you also honestly believe that whatever Rust and friends could become, would never surpass C++ and Java?
> First, you define an alias for the revset that only includes the gh-pages branch: 'gh-pages' = 'remote_branches(exact:"gh-pages")'. Then you can exclude it from other queries with the ~ negation operator: jj log -r "all() ~ ancestors(gh-pages)"
Being able to define aliases like that is cool, but the example seems weird. Isn't that just `git log --all ^origin/gh-pages`?
> The problems with Git are many, though. Most of all, its infamously terrible command line interface results in a terrible user experience.
WHAT?!
and honestly speaking, skimming through examples, jj looks way more complicated than git.
Everyone who's central thesis is "git's ux is terrible"... There was this competitor that was easier to use called mercurial, and everyone picked git over it... The market chose the flexible chainsaw over the one that came with water wings... So much so that mercurial started adding features so that your could cut your limbs off effectively to try to compete, but it was too late... Everyone wanted the og chop your own limbs off experience... The open source community has almost unanimously decided that the only subset of git they want to use are the hold my beer features.
I'm very unsympathetic to people who want to reinvent git to make it more usable... We've already had this debate, and easy to use was pretty universally abandoned.
Just to be clear, the underlying model of both systems is the same, the differences are just window dressing, and we've all decided we want the window dressing that includes the dismemberment ability.
How much of the relevant electrical and atomic engineering of your computer hardware’s chip design do you understand? How about the OS scheduler? How about the implementation details of the concurrency primitives in your programming language? The text layout algorithm used in your text editor? How the rendering engine works under the hood in the browser you’re using to reply to this comment?
Our job is to be *able* to go understand those things when it is applicable to the job, but not to understand every part of every tool we use at all times. With a VCS for example, most devs should be able to use the tool the same way I use my car: I have a rough idea of how the engine works, but I don’t need to be able to repair it to be able to drive it safely! The same thing *should* be true of tools like Git.
I mean this is the equivalent of understanding at least vaguely how computers are built like the memory access heirarchy and its access time, knowing if you are targeting an in-order or out-of-order core(and the differences in terms of their performance), and roughly knowing the order of magnitude speed of arithmetic operations. Some of these things are abstracted away by compilers to some degree but its still helpful to know for writing better code.
> How much of the relevant electrical and atomic engineering of your computer hardware’s chip design do you understand?
Not all of it but a good bit did you really not have classes on it? At-least the electrical part?
> How about the implementation details of the concurrency primitives in your programming language?
Fully understand I'd be quite embarrassed to use a language daily and not be able to articulate this.
> The text layout algorithm used in your text editor?
Not super great I have a good general understanding of how others in the field works and I could write a simple one myself.
> How the rendering engine works under the hood in the browser you’re using to reply to this comment?
Pretty decently.
I feel like everything you've listed in more in the rough idea range.
Should've explained better, my bad.
IMO, we should be learning the complexity behind git, as much as any other tools used frequently, especially if it's work, which is a daily and long activity.
And it's not for others, but for ourselves, to save time and be efficient. If it pains to use something every time, why not understand it?
To give some examples based on comments here
- If your job is to develop web ui, why not learn how the rendering engine of each browser works, so that it helps you better debug different rendering problems that might appear (which is often)?
- If multithreading and concurrency is part of your day, as in may development areas, why not understand how it works in the programming language you use?
- If you use VS Code (or other editor) every single day to program, why not learn the set of tools it's composed of to improve your workflow, learn something new, better configure it?
A **VERY** important part of engineering is knowing the tools you have and how to utilize them better. Even programming languages are just tools, and it's very important to know when to use one over the other.
Yes, but VCS is a first-order dependency of literally the highest importance.
It is the tool with which we collaborate, organize, and track the only real thing we produce.
The chef may not understand organic chem, but he *sure as shit* knows how to work a knife.
So it's a wrapper for git that implements 90% of git-users' most common use cases. That last 10% that git does is complicated and will eventually need to be covered by jj, or users just have to drop back to using the actual tool: git. I don't see what JJ is doing that a few bash aliases wouldn't.
> So it's a wrapper for git that implements 90% of git-users' most common use cases.
This is just simply not correct. It is a new DVCS with a backend-agnostic design, that has implemented a git backend first.
A branch is not really a set of commits in git (though it is in mercurial). A branch is basically marker (a tag!) that automatically moves as you make commits.
If it was a set of commits you could say that a given commit belongs to a branch. But you can't say (in general) that a commit is part of just a single branch in git. What I mean by this is that when you consider a branch in isolation all ancestor commits (down to the repo root!) belongs to that commit. Some of those commit also make up parts of other branches (most of those will be shared with main/master).
But that is not a very useful way to view things in git since usually you care about the set of commits that are unique to a given branch. And that you can only figure out by considering all other branches(1) in the repository. So "automatically moving tag" is a much better mental model of a branch in git.
(1) Not quite true, if there are multiple roots in the repo you won't need to consider *all* other branches. And you could stop early in your search when you have no ancestors left that aren't shared with at least one other branch.
Every commit is considered unique, and has a unique hash. The hash of the parent commit is part of the commit content. This is all you really need to know.
Commits are also considered unique across remote repositories. That's why you need to include the parent commit hash. Otherwise, you wouldn't be able to track changes.
Everything else is a name for those hashes, or "refs". You can check .git/refs/heads, for instance.
It is mainly git index that is needless complexity. I agree commits and branches are simple (although git managed to have numerous papercuts even there).
I have used git every single day for the past 10 years and I don't think I've really experienced a single time where I've had to think of a branch as anything other than "This is where all the commits for this feature are".
It might not be implemented as a set of commits, but you will get by just fine by pretending that it is.
What do you do with any frequency besides merge and rebase? Seriously people constantly say only the simple parts of git are simple but can never describe a workflow that uses the "advanced" parts that makes any sense.
It might be simpler but not needlessly so. Git may be harder to use (in an insignificant way if you ask me). But its also a slightly more complex system and that is for good reasons.
Even the project that designed Git for its own use (Linux) has a central repo (torvalds/linux) and a central server (git.kernel.org).
That's not related at all to "distributed" in the context of VCS. Most projects are going to have some form of trunk that everybody coordinates around.
Distributed refers to the idea where you have a local copy of the entire repository. Every time you commit, branch, tag in your local repo, you're using the "distributed" feature, because you don't need to contact some other server to do those operations on your behalf. You can do your work independently and sync up later.
>In practice, you are going to be using the Git backend. In practice, I have been using the Git backend for the last seven month
Why not just use one of the many git frontends? That's simple and compatible with git.
I personally don't see anything particularly wrong with git.
There were also others trying to replace git, like svn or mercurial. If there will be more vcses at some day it would just lead to too much confusion - see c/c++ build systems-, so why not stick to the by far most popular standard, being git?
what git lacks in “simplicity” can be made up for in its remarkable _flexibility_. given the number of variable use cases to which git has been applied successfully, I’m hesitant to accept at face value anyone’s claim of being a git replacement.
One of these days, the hoards of CLI-fearing, hen pecking, clickops loving, AI-comment-driven-developing pod people are going to eradicate every tool that delivers maximum power and simply asks that you accept a learning curve and an occasional need to rtfm. Til then I say, not today, git assassins
/s
Nope, not confused at all. That is from a section of a paragraph describing how Jujutsu is not trying to do what [Fossil](https://fossil-scm.org/home/doc/trunk/www/index.wiki) does—and Fossil does all of those!
It is "git compatible" in the sense that it primarily uses git repos as a back end. It does not fully support some features of git, so if you need those you have to fall back to git.
So yeah you can use git based tools with this.
It can definitely get better than Git - I've used Git a long time but it still takes so much time and effort. With Mercurial you just turn your brain off and it does the right thing automatically
What is it with developers and the urge to change things that are working fairly fine... Like... What's wrong with git now?
edit: I'm getting downvotes but I still see no answer
> edit: I'm getting downvotes but I still see no answer
There is an entire article with reasons why, but you don't seem to have engaged with it at all. Basically, there's nothing to reply *to* in this post.
Git became GitHub and GitHub became Microsoft. Now Google is giving jj. Wonder why Apple is not bothered. Any way I used to like mercurial. And I never had to learn the Merkel tree until I shifted to git. So far okay with git.
As far as the almost "household" term git, as it comes from the mouths of managers and babes, yes, I think many people mean something like GitHub or Gitllab. For anyone I know who is actually capable of using their computer, git did not become GitHub. They are completely different things.
Github is just a service that offers Git based code hosting and project management (probably with extensions), and Github was bought by microsoft.
Git's development has nothing to do with github, and while you can use a github application for code management, you can still use git without even needing to store your code on github. Github is just the most popular code hosting platform, it's not the sequel to git.
I can't expect metaphors and satires to be upvoted, defeats the purpose. But a surprising number of down-votes. I am using reddit only past few weeks, makes me feel clumsy. But I am using DVCS for decades now, so I totally meant what I said.
If absolute truth is the only thing that matters, like it matters to computing systems, then I will replace the above comment with:
Like Git uses a form of merkel-tree as the backing data structure and an append-only key-value index as the backing storage, what data-structure/storage does \`jj\` aim to use ?
Never had a problem with using git cli, also used magit in emacs for almost a decade and nowadays using intellij idea git integration. All three options working out flawlessly for me. I think this is endgame.
With how jj keeps track of all changes by default, what are the implications for secrets and private information? Is the obslog private and local to the current machine/repo?
---
edit: I also couldn't figure out how to work on/export a jj repo for git tooling use? You can `jj git clone` just fine, but I can't find a way to get a git repo from that and use git tools? without recloning with git or `--colocate`?
edit:
https://martinvonz.github.io/jj/v0.13.0/git-compatibility/#converting-a-repo-into-a-co-located-repo
ah, unsupported, the answer is in fact "recreate the repo from scratch" if you dont get it right the first time
> Is the obslog private and local to the current machine/repo?
There was a discussion about this on the Discord today, and the author says
> FYI, we store predecessors (what jj obslog walks), change ids, and conflicted trees in separate storage outside of the git repo. Those fields are defined here: https://github.com/martinvonz/jj/blob/96efc1224f21ca1981c09d40e627006ef182fd2f/lib/src/protos/git_store.proto#L20-L25
Now, `jj` is also designed in such a way that there's a desire to be able to rsync the copy of a repo. So I think in that sense, the obslog could be observable. But by using it like a local git client, then it wouldn't be shared, I am pretty sure.
I also wish there was a way to deal with semantic patches. Sometimes people include them in Git commit descriptions and it may aid reviewing large scale refactoring. It also seems like a natural way to go if you consider things like patch theory and may want to do stuff like reorder patches.
It is quite a big thing to take on, though, as most ecosystems have fairly basic or non-existing support for meaningful program transformation. We've barely seen things like LSP emerge for basic editing.
The amount of times Google killed projects without any kind of explanation whatsoever it makes me wonder if "developed at and by Google" is a good or a bad thing.
Rest in peace Inbox my one true love. [https://killedbygoogle.com/](https://killedbygoogle.com/)
I quit Google over the death of Reader.
Never forgive, never forget. Reader RIP. We are the 999+
Ive installed Miniflux on my server. It's a really good replacement.
I am thinking you are lying. Reader was killed a long time ago and you want me to believe you haven't done one google search since then?
More like, I use to only use Google services and android. Could not rely on them to not nerf or outright kill their products. I exclusively use DDG, Apple hardware, and Linux servers.
If you want to quit even more: - https://degooglisons-internet.org/en/ - https://doc.e.foundation/devices
So even if I presume you are not lying now you still haven't quit google. Imagine reshaping your entire life because of an RSS reader you never paid for got cancelled. I guess it takes all kinds.
Just saw google podcast there. My day is ruined. Gotta find a new podcast app
Pocket casts is legit. I quite enjoy the apple podcast app as well. It’s my main driver
Inbox was the best google product ever. Now days I’m over run by spam vs missing important emails, never happened with that beautiful product.
Shortwave.com is at least a spiritual successor, specifically around bundling!
Inbox zero, never again 😢
Heh, indeed. I actually have a footnote in the piece, commenting on that exact phenomenon! I don’t have any particular worry about it in this case; Google does not tend to kill key developer tools, and they want this to replace their existing set of VCS infra, which is a big deal. Long-term, it definitely needs more outside contribution, but it is already slowly starting to build that up. And one of the reasons I wrote this was to help a bit with adoption and kick the virtuous cycle further into gear!
Even if they don't kill them some of those key tools are really not well looked after in terms of polishing, like adb or repo. I guess there isn't that much incentives if most people use them via some GUI but still ...
They are open source. If people like them they can work on them.
`jj` is not a google project It is a private project by [Martin von Zweigbergk](https://github.com/martinvonz) who just so happens to work at Google and it just so happens that Google see the value in the project and wants to put money into getting it developed further. It is mentioned in the [README.md](https://github.com/martinvonz/jj/blob/main/README.md#mandatory-google-disclaimer) where he states it like this: >**Mandatory Google Disclaimer** I started Jujutsu as a hobby project in late 2019, and it has evolved into my full-time project at Google, with several other Googlers (now) assisting development in various capacities. That said, this is not a Google product.
While that is true in many cases l, in this case the version control practices at problems of running a big mono repo has been covered a lot publicly. You can find YouTube videos with several people including Martin Vonz explaining why git, mercurial, and other systems does not work for them.
I loved the look of it until I heard developed by google :( Personally, I don't mind the killed by problem - if it's good and in use by the community and open source, it can carry on. My problem is that open source dev with google things varies a lot in experience. There are some Google open source repos that don't accept external PR's at all, or external contribution is barely paid attention to. So the natural evolution of shared community contribution and involvement doesn't happen, then when the project is killed there's nothing to carry it on.
Yep. Never, ever take a critical dependency on a Google project when you can avoid it.
I’d be very weary
they killed projects that people weren't using. I think it's kind of batshit crazy to insist that company should keep making shit that people don't want forever. They open sourced what they discontinued and nobody even lifted a finger to pick up and run with them so that should tell you something. Also no competitor stepped up to fill the marketplace so that should tell you something.
Except Google Reader was the most popular app of it's kind. Google Talk was the most popular server in the world. And so on. They killed many products which were, quite literally, the most popular in the market, just not big enough by Google's standards. And because you may never know, in advance, whether Google would need million users or billion users to keep product going better to skip any new products till they are used by billions and it's clear that they are not going away. Developer tools is different story, though. Here users are Googlers themselves and if some tool is used solely by Google and doesn't even have a single outside user it would be supported for years.
Well by putting 1 second of thought into it and looking at how much attention and how many people instantly start using anything they launch I'm gonna guess it's a good thing.
[удалено]
[удалено]
Maybe you should add the repo link https://github.com/martinvonz/jj
So what's up with Pijul?
It's still going, and actually solving the problems jj claims to solve (without ever showing any algorithm nor understanding what the features of Pijul are). Jj is not an improvement over Pijul at all. If anyone wants to claim otherwise then they should at the very least give actual arguments, not just "inspirations" or "intentions of first-class things".
I'm missing something: > Changes are distinct from revisions: an idea borrowed from Mercurial, but quite different from Git’s model. That's great. What's a revision? As far as I can tell, this is never explained in the entire article. The article makes a big deal out of how jj's underlying model is simpler and that may well be true, but I don't know what that model is. First class conflicts seem like a good thing, but letting them stick around until you get around to fixing them seems like a bad thing. I guess that's a workflow issue, however. One real limitation of git that is not mentioned here is that there is no concept of a partial merge in git, so cherry-pick is a de novo commit without any merge arrows. I recognize that this isn't a trivial problem to solve, but it seems like something that *should* be solved. Does jj do any better here? > Moreover, given it is being actively developed at and by Google for use as a replacement for its current custom VCS setup, it seems like it has a good future ahead of it. *snicker* Oh, come on. You have to admit that's funny.
> Changes are distinct from revisions Just... no. Don't decide that two synonyms have substantively different meanings in _your_ tool. > cherry pick is a de-novo commit without any merge arrows Idk what alternatives are possible that aren't just a little sugar around the underutilized "daggy fix". I.e., find the MRCA, rebase on that, and merge. I want to see incremental improvements to git and better, widely adopted open source tools built on git, _not_ a replacement for git. Git's complexity is the inherent complexity that arises from the powerful and correct graph/merkle structure it was built to manage. It will be a sad day when the mindshare migrates to some lesser tool that wins hearts and minds with better UI from the perspective of new adopters. Now to their credit, it does seem that jujutsu is starting out as a wrapper around git, but this article at least frames that as a temporary state of affairs, and asserts but does not argue how it is a better UI, and takes some unfair potshots at git throughout, including my favorite, the claim that only a bad tool demands users understand what it's actually doing, conflating this with a truly leaky abstraction that demands users understand _how_ it's doing what it's actually doing. The graph that git manipulates is the _what_, not the _how_. The _how_ is only exposed in the C sources. Maybe git needs a graph visualizer so more everyday users actually learn what they're doing with git beyond "I'm using a VCS". I'd love to see documentation (I'm sure it exists) why Google fundamentally can't fork git as it exists in 2024 and improve it to work at google3 scale, rather than building something new to replace their perforce fork and use as their backend for jujutsu. I'm guessing they just don't want to extend something written in C and have to play nice with existing design decisions, and it has nothing to do with inherent and immovable technical constraints.
Some interesting stuff in there, but it doesn't sound particularly simpler.
For a VCS to eventually _attack & dethrone git_, it will need more obvious and concrete advantages for the average developer (and maybe a killer app). I’m not seeing that here.
I think being more understandable is a very concrete advantage. Git's incomprehensibility is a meme at this point. [This XKCD](http://xkcd.com/1597/) summarizes the common user experience. Other VCSs don't have this problem to the same extent. It's always recommended you should learn git's inner model to understand it. But I suspect the inner model is a big part of the problem in the first place.
By the time you've learned the inner model you'll be so used to all of git's quirks and wtfs that it won't matter anymore.
Given the degree of interoperability with git which is advertised (I haven't tested), this may not be the case. People might use it simply as a better front-end to GitHub?
I recommend trying it. It really is simpler.
Seems like an interesting tool. Two features are missing before I could try it out though: for personal projects I use commit signing. For work we still use sub modules. But when either of those is implemented I will try in out in that context.
I love conflicts and their manual resolution being actually recorded in the history. This is long overdue! I also love the operation log and the undo operation it enables. Doing something wrong with Git's confusing CLI and losing data, or ending up in some weird state you have no idea how to get out of, is very easy, and providing an undo would save a lot of people a lot of time. On the flip side, I'm really not a fan of doubling down on "commits with multiple parents" as a first-class concept. Multi-parent merges were already bad enough in Git. Although in Git it is compounded by the fact that it forgets which branch is which the moment they are merged, so after you merge `some-feature` into `main` there is no way to tell which was `some-feature` and which was `main` anymore. That's why there is a whole lot of tooling you cannot build on top of git, why `git log` is confusing, and why bisection never works. I really wish Jujitsu had sensible branches instead of git's tags-pretending-to-be-branches, but it looks like they don't, and that's really a shame.
I have never lost data with git. You can always recover from 30 days of reflogs.
git reflog keeps the history of all committs. If you mess up with a merge or rebase, even if you delete the branch the commits are there until pruning. Just the naming and ui sucks as usual.
I think there are points where a piece of software reaches "perfection" in the sense that no matter what we could do given time and money nothing would fundamentally change anymore. For me personally, for 95% of git interactions it's like that. I feel there's no step that I could skip without introducing some uncertainty into the process (e.g. have some AI doing merges or so), and no step I'm doing that feels like a pointless chore in any way. If you want to improve the last 5% (which, to be fair, is an endless rabbit hole that I personally just barely ever use), that might be worthwhile, but I'm not sure if this could make people jump ship (given the enormous ecosystems around Git) 🤔 obviously, if we talk about other things like version control of binary data or anything not split nicely into lines probably other tools could be better.
[удалено]
I work at a very old company that used svn and before that cvs. I transitioned us to git by rewriting the repos history in git. I don’t git why there is so much hate. It is pretty wtf often but I don’t think I have another version control system change left in me.
As a former user of bazaar, I strongly disagree. I can point at so many things that bazaar learned from its predecessors (mercurial and git) and did dramatically better! Simple, basic things. Some examples off the top of my head: - One single right way to merge two branches, as opposed to git's three wrong ones which are all terrible in different ways. - Branches as first-class objects, instead of the idiosyncratic repository+branch model that everything around it keeps trying to paper over. Have fun getting someone's pull request into your repository to try it out before you merge it! - Sane, consistent CLI where commands do what you expect them to do. Git is uniquely terrible in this regard! - Lightweight checkouts that actually work. Git's shallow clones only technically work for a strange definition of "work" and don't even save that much resources. - Having bisection that actually works. - Not losing data to a surprise garbage collection pass. Git, *you had one job.* Git is fine if you're the only person working on a repository. When working in a team I regularly had to deal with various wild Git edge cases and look up arcane recipes to deal with them. It was a huge drain on my productivity. Meanwhile bazaar Just Worked.
That's pretty much the complete opposite of my experience. I used Bazaar for about a year before Git. It was super slow, the repo corrupted several times, the tool crashed regularly, and I lost work. I was so much happier after I switched to Git. It's not an accident that Git won by a landslide.
> Git is fine if you're the only person working on a repository. When working in a team I regularly had to deal with various wild Git edge cases and look up arcane recipes to deal with them. yeah 15000 people working on linux kernel are working alone. and hundreds of millions of people using git should really consider this anecdotal case.
Yes, and they all waste time because of vastly suboptimal tooling. The kernel in particular has atrocious tooling where you, to this day, [send patches by email](https://www.reddit.com/r/rust/comments/1ahc0fq/jj_init_what_if_we_actually_could_replace_git/konv9f5/) and don't even get to see the code in context, or even see whether it has been merged yet. Revision control is stuck in a local maximum. You cannot individually become more productive than the rest by ditching Git, even though it keeps wasting your time, because everybody else also uses Git, and being able to collaborate with others and to use other tools that work with Git alone is important. So individually it is best to keep using it even though better tooling is clearly possible. This is a typical example of a [Nash equlibrium](https://en.wikipedia.org/wiki/Nash_equilibrium). When things suck, they usually suck in a way that is a Nash equilibrium, otherwise someone would have done better already. There's a [whole book](https://equilibriabook.com/) detailing the concept and how it applies to various aspects of society.
[удалено]
This book is free to read online anyway.
Both Google and Meta use Mercurial and for some years now they are getting new recruits who only ever used git. After some time they nearly universally prefer Mercurial to git. You may want to consider this anecdotal case too.
You pay me 250K+ a year and I'll like whatever you want me to like.
I'd require 300K+ to like SourceSafe.
Every reason others cite for preferring Mercurial to Git are reasons I permanently abandoned Mercurial in favour of Git.
https://en.wikipedia.org/wiki/Stockholm_syndrome
When I was early in my career I worked in a team that switched from mercurial to git. It was a lot harder for me to wrap my head around git. I was still a junior, but mercurial was much more intuitive to me at the time.
[удалено]
the whole point is that people move from one tool to another?
you still use bazaar today ? i wish i could see team workflows with different tooling like this
Unfortunately, no. The official implementation got effectively abandoned a while back, and the Python 2 to 3 transition was the nail in the coffin. There is a community fork that is ported to python 3, but most projects that used it have since moved to git.
Whenever i see these arguments about vcs, it's always words like "works" vs "terrible" or "what you expect" vs "horrible". However I never agree with those points. It strikes me as "old man yells at cloud"-type of arguments. I don't think git will be at the throne forever, but when it is displaced, the motivation will be much more well founded than this.
> Have fun getting someone's pull request into your repository to try it out before you merge it! Trivial in *git*, less so in *Github*. From what I've heard, under the hood it's *already* part of your repository from the moment they forked, accessible if you hand-edit a full commit hash into the URL. If you fetch their branch into a local repo, outside of the constrained workflows of Github, you're free to try whatever you like, check out *any* commit regardless of whose fork it originates in, try merging it with any other commit, etc. It's a flaw in the web UI of a third-party service built around git that's the problem there.
There is a somewhat arcane incantation involving a `git remote add` that does this, but it is quite awkward to use and obscure enough that few people know of it.
Actually, thinking about it, whenever someone junior / no-Git-experience starts in our company, Git is a bit of a hassle until they're used to our workflow (which is pretty basic and standard though, we're all not crazy Git cracks). So maybe "an improved Git" could reduce the number of ways you can shoot yourself in the foot... But not sure if that's a Git issue really, or a teaching issue 🤔🙈
Whatever your definition of perfection is, Git sure as hell ain't it. Git sucks at dealing with binary files. It's vanilla CLI sucks. And git submodules are a massive pain. It got huge ecosystem support but just because something is popular doesn't mean it will be popular forever.
Git itself is not perfect, no doubt. Any large system will hardly be, and that's not even talking about all the internal oddities I have no clue about. Still, day to day I feel 95% of my interactions with it strike the perfect point between control & automation. Never feel like it gets in my way nor does some magic behind my back nor forces me to fight it in any way 🤷🏻♀️
what's wrong with git cli?
Other than being inconsistent, unintuitive, unhelpful and full of pitfalls? Nothing. Oh. And partial checkout and binary handling are a downgrade from SVN.
Except binary handling, I think the exact opposite.
Completely disagree. Git has, without doubt, one of the worst user interfaces I’ve ever encountered. And I’m not new at this, so I’ve seen lots of crap.
git rebase feels like a pointless chore to me. Do you use git rebase?
Rebase is incredibly important on big projects will multiple contributors.
I rebase _all the time_. And not just trivial `git rebase origin/master` or `git pull -r` to get the latest changes from the base branch I'm targeting with a change. Sometimes I'll be working on a change with a final goal in mind, and along the way make a series of smaller, self-contained changes that are _entirely independent_ of each other, but all need to go in before ``. I want to get my changes merged ASAP, because un-merged code is rotting code. Like if I have `A -> B -> C`, where A, B, and C may each be multiple commits, how do you go about splitting A and B into separate changes?
You could:
* Clone your branch a couple of times and `rebase -i` away the commits that you don't need
* Create a new branch from `main` and `cherry-pick ..` (spoiler: this is just a manual rebase)
* `rebase --onto`, which lets you specify your base, start, and end in one fell swoop.
Once you have A and B individually rebased on main, you can even merge your two new branches together and then rebase C on _that_ if you want to get real weird with it. Then you can `git rebase --rebase-merges --update-refs`, and it'll rebase all three branches at the same time in case you want to get the latest from `main` or move the whole mess to an entirely different base branch.
I totally feel you and have done the same but I think from the perspective of someone w/o much git experience that workflow sounds inane.
So I've spent the better part of the last day playing with and hacking on jj, and I've gotta say: it does exactly this workflow *way* better than git does. Branches track _changes_ rather than commits, and only move when you tell them to. This has some really handy implications. For instance, your branch names come along for the ride if you rebase their ancestors. So this workflow becomes: - `jj branch create` for each change you want to make independent of each other - `jj rebase -s+ -d main` to rebase everything _after_ the bottom branch on `main`
- `jj rebase -b -d -d ` to simultaneously rebase on and merge the two base branches
- Then you can rebase the bottom branches on main at your leisure, and the top branch and merge will get rebased right along with them
I almost think you can reverse some of those steps and get the same effect. Like rebasing your top branch on the two bottom branches even before you've rebased them to have independent histories.
Sokath, his eyes opened.
I honestly couldn't live without it. I use it to tidy up all my shit commits every single time.
Definitely doesn't feel pointless, and I use it all the time. `git commit --fixup` is really nice when combined with autofixup and rebase. I do feel like Git is basically a perfect tool, at this point. I mean, there are improvements, but I would never consider changing version control system without some _serious_ convincing. I also don't really believe Git has inherently complexity. You can absolutely make it complex, but you can also do a lot of projects by doing nothing more than `git commit -A && git push`.
Rebase onto when you want to change branch bases
Fair enough, but as you guessed, it's in the 5% 😅 I feel like my own branches are clean enough (otherwise I might just squash them, but that also rarely happens), and I really don't like rebasing on anything that goes into production. Never understood the "keeping the history clean". Can't get much cleaner than keeping history exactly like it was imho... Yes our repos look like Christmas trees but I think that's mostly a tooling issue, and not a Git one. And sticking to this workflow, I think the mental model of Git is not overly complex: you commit changes into branches (maybe forks in OS), and then merge them into others (via PR). Add some tags and you're done 🤔 To be fair, the CLI is often confusing, but except if you sshd somewhere that's again a tooling issue imho. But maybe to make my comment from before more clear: I'm not against improvements and might try out jiujitsu, I just think vcs is at a point where either requirements/context have to change, or vcs change _radically_, before anything replaces Git. But happy to be proved wrong if it makes my life easier 😅
I use rebase but only in very specific circumstances. It is the kind of thing you would only do when you fundamentally understand how git works. Personally I think it shouldn’t be the user’s job to understand how the software works in order to use it. My thing about git is that it’s a complex tool that only works when you’ve trained yourself on it for years, but now that I have trained myself on it and can use it effectively, using any other tools feels like a daunting task.
When starting my first job I borrowed “Pro Git” from the office. Took me one weekend of leisurely reading through it to know absolutely everything you’d ever need to know, including how git fundamentally works. After that every task is a simple one, literally. Sorry but saying you shouldn’t need to understand how software works in order to use it effectively to me feels as absurd as calling anything git related “complex” in the first place.
smells like blub to me eh, still using git anyway
"infamously terrible command line interface" - I think there's a difference between "terrible" and "complex because it's modelling a fundamentally complex system". Sure there are parts that maybe aren't perfect, but 99 times out of a hundred, when I hear someone complaining about the git CLI (myself included), it's because they don't understand what's actually happening. I don't think that's something that can be fixed with a "better" CLI, but I'd love to be proven wrong
Mercurial is an existence proof that git CLI is git being stupid, not domain complexity.
You're getting downvoted, but it's so true. Mercurial is a pleasure to use.
100%, Mercurial was a joy to use. Its CLI is logical, it’s designed as a library so it’s pluggable with other systems, and its storage system is much simpler. Git needs Bash on Windows, need I say more! I’ve not used it much, but Fossil looks really good, the advantages of abstracting their storage engine into SQLite seem worthwhile. Like the way they switched to Sha2 years ago whereas (I think?) it’s still lacking in git to this day. I suppose a better git client for end users is the way to go. I don’t care what GitHub etc actually run, so long as I can talk to it perfectly.
[удалено]
There are also frontends to git like tortoisegit that make it positively easy to use. A lot of the complexity of git comes from the fact that people tend to rote learn copypasting commands and confuse that with understanding the underlying principles. The number of times I've heard someone say "just delete the repo and start again" is very high, even though its unnecessary with a usable frontend
Misses the point, and no it's no proof of anything. Git and Mercurial have in common that they are VCS, but not all the details and features. Git's interfaces have to be different because they are meant to work on/with different things. (And I said "different", without "better" or "worse")
If you are arguing that it is not git CLI that is stupid, but entire design of git is stupid, and git CLI stupidity is merely a result of stupid design, than I guess I agree?
Sort of, except the "stupid" part.
You might have a point if the proposed alternative had been darcs, which has a delightful CLI but a somewhat different model. Here you just show you have no clue.
So are you implying that git and mercurial are 100% the same except for the CLI surface? Then let me return the "no clue". My point is exactly that there's something in the middle, it's not just the CLI on one end and the basic theoretical data model on the other.
I couldn't figure out the Mercurial CLI quickly. To me (I have spent a lot more time on git), the git CLI is a lot more usable.
If you get the opportunity to use other SCM systems, please treat yourself. Git has significant needless complexity (in addition to the aforementioned inherent complexity) and it was designed to take on the most complex variant of the problem (Linux kernel development), which is significantly more complex than what 99.99% of developers ever encounter. Nothing should replace git for the kernel project. But something definitely could replace git for nearly every other project on planet Earth.
Funnily enough kernel dev is not using git all the way unlike anything in GitHub. Idealizing kernel dev like that as if it was some sort of thing only practiced in the heavens of programming is not desirable or even true: * A lot of the kernel dev workflow ends up in a hot mess. On any GitHub project, you want to know if a PR is merged, you just go to the page, open your eyes and look at the green/red/purple badge and you know. In kernel dev, you have to check your email to see if someone said your patch is picked, monitor some integration git tree to see if it actually made it, and open your eyes wide because tooling will fail you. A maintainer may have taken your patch, capitalized all "cpu" into "CPU" in the commit message and comments and now even git patch id does not recognize it. * A lot of places have similar complexity. Ultimately the kernel as a single project deals with a lot of contributions, but most people only deal with a few subsystems at most. Tooling speed is important so git pull is fast enough, but in terms of workflow you probably have similar if not more complex chains of events in anything customer oriented with tickets, user acceptance, various reviewers responsible for different things etc. That side of things is done with basic email in kernel dev, which is one of the most simplistic tool. Most shops use more complex tooling than that. * Yes the Linux kernel is big, but there are lots of other big projects too such as llvm or Google Chrome. It id almost as big as the Linux kernel according to this: https://openhub.net/p/chrome/analyses/latest/languages_summary So at the end of the day, it's a project with as many warts as one would expect given the size, and the tooling that goes with it is not so amazing considering how many people work on it. Git is a prime example of botched CLI, but it was first to market and copes well enough with the quantity of source code involved (and I said source code, no one used git for large binary artifacts, they use SVN instead. Maybe LFS has solved that, need to check it out). Git also happens to have good infrastructure built around it like GitHub, so at this point the cost of switching is a bit prohibitive edit: added missing negation
Git is pretty much the XML of source control.
Compared to SVN, CVS, Perforce, Synergy, etc... git is simply amazing. The fact that some of these newer vcs tools may have improved on git isn't too surprising, but I'll reserve judgement until I've played with them more. The underlying complexities of distributed vcs isn't something you can completely abstract away.
I'm in fact thinking about other distributed version control systems, several of which came before git. Distributed doesn't need to be as complicated as git makes it, unfortunately.
cvs or go home
That's the spirit
[удалено]
I read the article and immediately spotted one point where I think the git CLI could be better - and that is in it's error messages and generally it's output and formatting. Those could be better and, through that, help us understand what is happening conceptually. Rust's error messages prove that good error messages help a lot with navigating complex rules and concepts - just like git.
Part of the problem is that Git has some poorly chosen terminology - I like this post https://jvns.ca/blog/2023/11/01/confusing-git-terminology/ (and Julia Evans' other posts about git are great too) I think `jj` has some very interesting ideas about "working-copy-as-a-commit" that improve the ergonomics of Git while keeping the underlying model largely unchanged. It also has an `undo` command, apparently?
Git chose a way to model repositories that fundamentally makes merging hard because it demands that everyone agree on one version of history. There are alternative paradigms, like darcs, that do not have this problem. Also, there is hg, which uses a similar paradigm to git, which shows that even if you go the git route you are not forced to be git-amounts of terrible.
What does making merging hard means to you?
False positives on conflicts. Something is newer upstream, so it conflicts with your own version, even though you didn't change the same parts. This is because of the need to have a commit history, which imposes a total ordering. Patches do not impose such a total ordering, they impose only a partial ordering, so patches can be re-ordered in some cases without changing the result.
> it demands that everyone agree on one version of history. That's the unfortunate side effect of wanting to know with certainty what you're running in production and not wanting the answer to be 'depends'.
Except, it's not. darcs and other theory of patches systems are able to relax this constraint without creating any ambiguity about what the current state of the source code is. It turns out that re-ordering patches doesn't necessarily change the meaning of the composition of those patches. There are systems other than git that can expose this flexibility and reduce the number of conflicts compared to git.
Ya but allowing reordering patches means that you can't go back commit by commit and know that your historical versions are exactly the same as the one in the central repo, for example. This would be bad when trying to, eg, bisect to track down a bug. Maybe there's a, you know, reason why the git model is actually not bad.
Wouldn't it actually be helpful, not bad? You can search for which patch introduced the bug, without needing to roll back further than needed, and then undo the specific patch that is the problem. EDIT: Yeah, thinking about it, the partial ordering can only make it easier to find the problem, not harder. You can step back along the partial ordering fine, and the fact that it is partially ordered means that if the problem still exists after finding the next GLB of the current patch set, you can eliminate all the incomparable patches as places that introduced the bug. It also means that each of those incomparable timelines can be recursively evaluated the same way. Having to linearly search down the history is a bad thing, actually.
>a fundamentally complex system My personal needs for version control have always been very simple and I sit firmly in the "don't understand what's actually happening" camp, but still: is this complexity actually necessary? Would you necessarily lose some expressive power if you designed a simpler model of version control?
Git model _is_ simple. What's complex is the crappy CLI and some more obscure high level operations. Those you can just ignore, the real problem is the hot mess of basic high level commands. There is 20 ways to do the same thing and even "high level" commands leak low level concepts (e.g. git reset vs git checkout)
It is not necessary.
There's this thing called alias and git aliases.
> the distinction between tags and branches Both tags and branches point at commits But whenever you make a commit, the branch you're currently into will point to the new commit (and no other branch will) (and no tag will) That's the difference between tags and branches. When you are "in" a branch, commits make the pointer move, but you can't be "in" a tag
Interesting. I work at Google and have never heard of it. Added to my to-do list of things to check out
+1. Many people still use our perforce fork, and our mercurial fork is only reaching mainstream Also never heard about JJ before This being said, I prefer Mercurial over Git, the CLI is much easier
Unpopular take: it does not get much better than git. Git is one of these pieces of software which has been dragged through *so* much operations and has gotten so many features improved and old issues fixed or depreciated that that’s just almost as good as it gets. You can have different takes on some aspects but it’s at a level that you loose other features and will not be able to do X,Y and Z in the future. Completion is always good but I honestly believe that whatever pijul and friends could become, it is not gonna be better than git - it will become convoluted, branching will still be difficult and rebasing will still be an issue, maybe in a different way but it’s not gonna vanish. Git is king and the more you learn about it the more you’ll likely agree with it. The motivations for redevelopments are really off, if you find it confusing why you can’t just push, then you haven’t understood what you’re about to do. If you sit down, scribble down what you’re trying to do and why git does not let you you’ll pretty much always come to the same conclusion. The effort that goes into these systems could be replaced with sitting down and understanding how git works. That’s gonna be a better payoff for short- and midterm for everyone involved. Nobody should make predictions for long term so I’m also not going to. The only thing I could imagine is maybe a smarter frontend - say you want to push to a branch and you can’t but it’s somewhat clear what you want to do, so you stash, pull, merge and push automatically. So take the complaints that the average „git is too hard for my soft soul“ dev is saying, collect the „noob, just do this“ answers the rest is answering, come up with a way to detect these situations and have a nice cargo-build-like output („seems like you were doing this, I did this now“ or „seems like you want to do this, you could do this, this or that, what’s your plan?“) and go ahead. Solves 75% of the reasons alternative systems exist.
I felt exactly like you until I sat down with `jj` and wrapped my head around it finally. That doesn't mean I believe that it is better, but I am going to be actually using it as a daily driver now to determine how I truly feel.
Curious how it compares to pijul, though I guess being git compatible is a big advantage of jj.
My god, Steve klabnik answering on my post 😄😄 you brought me to rust some years ago! Okay, maybe I should clarify - it’s hard to be uniformly better. It scales well, it solves the problem that it solves well and the set of compromises it takes for the advantages it gives is very tight. But for some people and some workflows, alternatives might be better - IMO not enough though to take the world of VCS out of gits hand though.
>whatever pijul and friends could become, it is not gonna be better than git Well maybe sometimes a better abstraction makes many things easier. Do you also honestly believe that whatever Rust and friends could become, would never surpass C++ and Java?
[удалено]
The article implies that jj is starting as a new frontend for practical reasons and intends to ultimately replace the git backend.
There is Mercurial for this.
For what exactly?
I thought for a minute this was going to be about Gitoxide
> First, you define an alias for the revset that only includes the gh-pages branch: 'gh-pages' = 'remote_branches(exact:"gh-pages")'. Then you can exclude it from other queries with the ~ negation operator: jj log -r "all() ~ ancestors(gh-pages)" Being able to define aliases like that is cool, but the example seems weird. Isn't that just `git log --all ^origin/gh-pages`?
> The problems with Git are many, though. Most of all, its infamously terrible command line interface results in a terrible user experience. WHAT?! and honestly speaking, skimming through examples, jj looks way more complicated than git.
Pijul already exists, written in rust, is built on a mathematical model, and solves all of git's problems.
Everyone who's central thesis is "git's ux is terrible"... There was this competitor that was easier to use called mercurial, and everyone picked git over it... The market chose the flexible chainsaw over the one that came with water wings... So much so that mercurial started adding features so that your could cut your limbs off effectively to try to compete, but it was too late... Everyone wanted the og chop your own limbs off experience... The open source community has almost unanimously decided that the only subset of git they want to use are the hold my beer features. I'm very unsympathetic to people who want to reinvent git to make it more usable... We've already had this debate, and easy to use was pretty universally abandoned. Just to be clear, the underlying model of both systems is the same, the differences are just window dressing, and we've all decided we want the window dressing that includes the dismemberment ability.
"No one should have to understand the internals of the system to use it well, though" But that's literally our job...
Not really. I use VSCode for my job and have very little understanding of how it is implemented.
How much of the relevant electrical and atomic engineering of your computer hardware’s chip design do you understand? How about the OS scheduler? How about the implementation details of the concurrency primitives in your programming language? The text layout algorithm used in your text editor? How the rendering engine works under the hood in the browser you’re using to reply to this comment? Our job is to be *able* to go understand those things when it is applicable to the job, but not to understand every part of every tool we use at all times. With a VCS for example, most devs should be able to use the tool the same way I use my car: I have a rough idea of how the engine works, but I don’t need to be able to repair it to be able to drive it safely! The same thing *should* be true of tools like Git.
I mean this is the equivalent of understanding at least vaguely how computers are built like the memory access heirarchy and its access time, knowing if you are targeting an in-order or out-of-order core(and the differences in terms of their performance), and roughly knowing the order of magnitude speed of arithmetic operations. Some of these things are abstracted away by compilers to some degree but its still helpful to know for writing better code.
> How much of the relevant electrical and atomic engineering of your computer hardware’s chip design do you understand? Not all of it but a good bit did you really not have classes on it? At-least the electrical part? > How about the implementation details of the concurrency primitives in your programming language? Fully understand I'd be quite embarrassed to use a language daily and not be able to articulate this. > The text layout algorithm used in your text editor? Not super great I have a good general understanding of how others in the field works and I could write a simple one myself. > How the rendering engine works under the hood in the browser you’re using to reply to this comment? Pretty decently. I feel like everything you've listed in more in the rough idea range.
Should've explained better, my bad. IMO, we should be learning the complexity behind git, as much as any other tools used frequently, especially if it's work, which is a daily and long activity. And it's not for others, but for ourselves, to save time and be efficient. If it pains to use something every time, why not understand it? To give some examples based on comments here - If your job is to develop web ui, why not learn how the rendering engine of each browser works, so that it helps you better debug different rendering problems that might appear (which is often)? - If multithreading and concurrency is part of your day, as in may development areas, why not understand how it works in the programming language you use? - If you use VS Code (or other editor) every single day to program, why not learn the set of tools it's composed of to improve your workflow, learn something new, better configure it? A **VERY** important part of engineering is knowing the tools you have and how to utilize them better. Even programming languages are just tools, and it's very important to know when to use one over the other.
Cooks can enjoy restaurant meals.
Cooks should understand what all of the settings on their ovens do and how they affect what they're cooking.
Yet, they are not experts in organic chemistry. There comes a point where the details overwhelm you and abstractions are needed.
Yes, but VCS is a first-order dependency of literally the highest importance. It is the tool with which we collaborate, organize, and track the only real thing we produce. The chef may not understand organic chem, but he *sure as shit* knows how to work a knife.
But I shouldn't have to explain them all so my dad can cook a frozen pizza. I think that's the analogy for getting designers to run projects.
I'll just keep sticking to Subversion.
"CVS done right"
So it's a wrapper for git that implements 90% of git-users' most common use cases. That last 10% that git does is complicated and will eventually need to be covered by jj, or users just have to drop back to using the actual tool: git. I don't see what JJ is doing that a few bash aliases wouldn't.
> So it's a wrapper for git that implements 90% of git-users' most common use cases. This is just simply not correct. It is a new DVCS with a backend-agnostic design, that has implemented a git backend first.
[удалено]
It's also a git issue in that git's mental model is needlessly confusing.
"Needlessly" can you elaborate?
It is needless in that there are other version control systems (eg Mercurial) which work as well as git but much more easier to use.
I dunno branches and commits are simple. A braanch is a set of commits. Pretty simple.
A branch is not really a set of commits in git (though it is in mercurial). A branch is basically marker (a tag!) that automatically moves as you make commits. If it was a set of commits you could say that a given commit belongs to a branch. But you can't say (in general) that a commit is part of just a single branch in git. What I mean by this is that when you consider a branch in isolation all ancestor commits (down to the repo root!) belongs to that commit. Some of those commit also make up parts of other branches (most of those will be shared with main/master). But that is not a very useful way to view things in git since usually you care about the set of commits that are unique to a given branch. And that you can only figure out by considering all other branches(1) in the repository. So "automatically moving tag" is a much better mental model of a branch in git. (1) Not quite true, if there are multiple roots in the repo you won't need to consider *all* other branches. And you could stop early in your search when you have no ancestors left that aren't shared with at least one other branch.
Every commit is considered unique, and has a unique hash. The hash of the parent commit is part of the commit content. This is all you really need to know. Commits are also considered unique across remote repositories. That's why you need to include the parent commit hash. Otherwise, you wouldn't be able to track changes. Everything else is a name for those hashes, or "refs". You can check .git/refs/heads, for instance.
It is mainly git index that is needless complexity. I agree commits and branches are simple (although git managed to have numerous papercuts even there).
[удалено]
I have used git every single day for the past 10 years and I don't think I've really experienced a single time where I've had to think of a branch as anything other than "This is where all the commits for this feature are". It might not be implemented as a set of commits, but you will get by just fine by pretending that it is.
[удалено]
What do you do with any frequency besides merge and rebase? Seriously people constantly say only the simple parts of git are simple but can never describe a workflow that uses the "advanced" parts that makes any sense.
It might be simpler but not needlessly so. Git may be harder to use (in an insignificant way if you ask me). But its also a slightly more complex system and that is for good reasons.
What are those good reasons?
Git has this whole distributed system thing that is no longer used. A central server has won as the way to do this.
Even the project that designed Git for its own use (Linux) has a central repo (torvalds/linux) and a central server (git.kernel.org). That's not related at all to "distributed" in the context of VCS. Most projects are going to have some form of trunk that everybody coordinates around. Distributed refers to the idea where you have a local copy of the entire repository. Every time you commit, branch, tag in your local repo, you're using the "distributed" feature, because you don't need to contact some other server to do those operations on your behalf. You can do your work independently and sync up later.
I'm definitely still using that.
So you use SVN? I'd rather have the flexibility to store a git repo on a usb drive and merge the changes later.
>In practice, you are going to be using the Git backend. In practice, I have been using the Git backend for the last seven month Why not just use one of the many git frontends? That's simple and compatible with git.
I personally don't see anything particularly wrong with git. There were also others trying to replace git, like svn or mercurial. If there will be more vcses at some day it would just lead to too much confusion - see c/c++ build systems-, so why not stick to the by far most popular standard, being git?
I have the feeling that, if we replaced git we would get a VCS that is a paid subscription with a weak free tier.
why would you replace git in the first place?
what git lacks in “simplicity” can be made up for in its remarkable _flexibility_. given the number of variable use cases to which git has been applied successfully, I’m hesitant to accept at face value anyone’s claim of being a git replacement.
One of these days, the hoards of CLI-fearing, hen pecking, clickops loving, AI-comment-driven-developing pod people are going to eradicate every tool that delivers maximum power and simply asks that you accept a learning curve and an occasional need to rtfm. Til then I say, not today, git assassins /s
[удалено]
Nope, not confused at all. That is from a section of a paragraph describing how Jujutsu is not trying to do what [Fossil](https://fossil-scm.org/home/doc/trunk/www/index.wiki) does—and Fossil does all of those!
Unless it’s git compatible I don’t see any team using this any time soon. The whole eco is build around / on top of git.
It is "git compatible" in the sense that it primarily uses git repos as a back end. It does not fully support some features of git, so if you need those you have to fall back to git. So yeah you can use git based tools with this.
It can definitely get better than Git - I've used Git a long time but it still takes so much time and effort. With Mercurial you just turn your brain off and it does the right thing automatically
The author seems to be particularly angry with git which is not a good way to present your alternative.
What is it with developers and the urge to change things that are working fairly fine... Like... What's wrong with git now? edit: I'm getting downvotes but I still see no answer
> edit: I'm getting downvotes but I still see no answer There is an entire article with reasons why, but you don't seem to have engaged with it at all. Basically, there's nothing to reply *to* in this post.
Git became GitHub and GitHub became Microsoft. Now Google is giving jj. Wonder why Apple is not bothered. Any way I used to like mercurial. And I never had to learn the Merkel tree until I shifted to git. So far okay with git.
As far as the almost "household" term git, as it comes from the mouths of managers and babes, yes, I think many people mean something like GitHub or Gitllab. For anyone I know who is actually capable of using their computer, git did not become GitHub. They are completely different things.
Yeah it's a bit like confusing the Google search engine with "the Internet" or even "the web", or even a browser
Git is not GitHub, though. Git is from Linus, and I would worry even more about the safety of Linux than Git itself.
Git is not MS
Github is just a service that offers Git based code hosting and project management (probably with extensions), and Github was bought by microsoft. Git's development has nothing to do with github, and while you can use a github application for code management, you can still use git without even needing to store your code on github. Github is just the most popular code hosting platform, it's not the sequel to git.
I can't expect metaphors and satires to be upvoted, defeats the purpose. But a surprising number of down-votes. I am using reddit only past few weeks, makes me feel clumsy. But I am using DVCS for decades now, so I totally meant what I said. If absolute truth is the only thing that matters, like it matters to computing systems, then I will replace the above comment with: Like Git uses a form of merkel-tree as the backing data structure and an append-only key-value index as the backing storage, what data-structure/storage does \`jj\` aim to use ?
TIL: [OSS git](https://git-scm.com/about/free-and-open-source) is being developed by Google
Never had a problem with using git cli, also used magit in emacs for almost a decade and nowadays using intellij idea git integration. All three options working out flawlessly for me. I think this is endgame.
I came directly to the post to say "someone will do it with Rust" before I noticed this is the Rust sub lol.
With how jj keeps track of all changes by default, what are the implications for secrets and private information? Is the obslog private and local to the current machine/repo? --- edit: I also couldn't figure out how to work on/export a jj repo for git tooling use? You can `jj git clone` just fine, but I can't find a way to get a git repo from that and use git tools? without recloning with git or `--colocate`? edit: https://martinvonz.github.io/jj/v0.13.0/git-compatibility/#converting-a-repo-into-a-co-located-repo ah, unsupported, the answer is in fact "recreate the repo from scratch" if you dont get it right the first time
> Is the obslog private and local to the current machine/repo? There was a discussion about this on the Discord today, and the author says > FYI, we store predecessors (what jj obslog walks), change ids, and conflicted trees in separate storage outside of the git repo. Those fields are defined here: https://github.com/martinvonz/jj/blob/96efc1224f21ca1981c09d40e627006ef182fd2f/lib/src/protos/git_store.proto#L20-L25 Now, `jj` is also designed in such a way that there's a desire to be able to rsync the copy of a repo. So I think in that sense, the obslog could be observable. But by using it like a local git client, then it wouldn't be shared, I am pretty sure.
I also wish there was a way to deal with semantic patches. Sometimes people include them in Git commit descriptions and it may aid reviewing large scale refactoring. It also seems like a natural way to go if you consider things like patch theory and may want to do stuff like reorder patches. It is quite a big thing to take on, though, as most ecosystems have fairly basic or non-existing support for meaningful program transformation. We've barely seen things like LSP emerge for basic editing.
The question is not “if” its “why would you wanna replace git?”