I am certainly no expert in version control systems, but I've gotta say that it's really wonderful to see a project that builds on the algorithmic and cultural successes of Git but with a simplified and modernized approach. The reason that Git took over the open-source world is two-fold: first, it was adopted by Linux, which ended up being the most influential OSS project of all time. Second, the Git model, which is…
> which is distributed and egalitarian at its core, is a better model for a fast-paced, globally distributed community of developers than previous monorepo systems like Mercurial I'm a bit confused by this. I don't think that's what monorepo means, is it? Monorepo is what you choose to put in a repo? And I thought Mercurial was extremely similar to Git as it's also a DVCS?
Jujutsu: A Git-compatible DVCS that is both simple and powerful
121–130 of 269 posts
Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful
#122Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful
#123Looks really cool! One thing I'm not clear on from the docs: does it support ignoring changes to some files for "real" commits? For example, a repo at work has a file used for mocking up feature flags. The file is tracked but it's encouraged to edit it when testing things, just don't commit your changes. If I'm not mistaken, I'd have to remember to undo changes to that file before "describing" the commit. Is that rig…
I know the nuisance of having to tiptoe around files you don't want to add to history. In case it helps your use case: git update-index --assume-unchanged git update-index --no-assume-unchanged This would ignore changes while you're testing - but you have to remember to turn it off or, iiuc, you won't pull intentional changes either. You might find hooks useful too. Not to assume your knowledge, these are shell scrip…
Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful
#124I haven't really used git on the command line for years now, except for some special cases. In my daily usage, I rely on the built-in IDE integration (IntelliJ, FWIW), and I don't understand why anyone would put up with doing it manually. I can do partial commits by selecting individual lines right in my editor. I can view all branches, merge them, cherry-pick from them, commit stuff or amend it, pull updates, edit t…
Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful
#125I haven't really used git on the command line for years now, except for some special cases. In my daily usage, I rely on the built-in IDE integration (IntelliJ, FWIW), and I don't understand why anyone would put up with doing it manually. I can do partial commits by selecting individual lines right in my editor. I can view all branches, merge them, cherry-pick from them, commit stuff or amend it, pull updates, edit t…
The skillset is portable across environments (I can remote into a box and look at a repo as easily as I can interact with one locally), across editors (I don't have to learn and re-learn how each editor interacts with the VCS), and I can use all my familiar tools to work with it.
As for those workflow examples, I can just as easily do all those things via the command-line. The editor integration isn't anything special. And when I need to something weird and advanced (e.g. interacting with the reflog), odds are I'm gonna have to bust out those command-line skills, anyway.
Why would that be so hard to believe?
Edit: BTW, to be clear, I have no issues with people using GUIs. If you're productive with your tooling, who am I to judge? But you asked why, so I answered why. I don't claim my way is any better than your way.
Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful
#126Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful
#127I haven't really used git on the command line for years now, except for some special cases. In my daily usage, I rely on the built-in IDE integration (IntelliJ, FWIW), and I don't understand why anyone would put up with doing it manually. I can do partial commits by selecting individual lines right in my editor. I can view all branches, merge them, cherry-pick from them, commit stuff or amend it, pull updates, edit t…
Or it's folks that think the base set of linux tools are the be-all-end-all of programming. ("Why use Dropbox when I can rsync", "Use the ext4 filesystem as a database and store metadata in inodes and use git for MVCC", "I will do sed | awk | cut | xargs find | tr instead of a 10 line python script").
Or it's folks that cult-follow one of the two groups above.
Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful
#128Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful
#129Nice to see this posted here. I switched over to it about 2-3 weeks ago, and I haven't looked back. It took a lot of mental rewiring, but I really enjoy the workflow `jj` provides. There's no longer a time to think about what's being committed, because all file changes automatically amend the working copy commit. Of course, sometimes you don't want this, so you have things like the ability to split a commit into two,…
It mentions that it can be used with backends like Dropbox, but it would be wonderful if we finally had a system that could easily be used with IPFS. This is especially important for large data, since you can't store 1TB on github (and no, I don't count lfs, since you have to pay for it).
IPFS is the natural solution here, since everyone that wants to use the dataset has it locally anyway, and having thousands of sources to download from is better than just one.
So if this uses IPFS for the data repo, I'm switching immediately. If it doesn't, it's not worth looking into.
Re: Jujutsu: A Git-compatible DVCS that is both simple and powerful
#130Earlier quoted context omitted.
Sometimes you have changes that are permanent to your repo (ie local workflow), that you always want to keep locally, but never push to the remote. In git you would always leave the changes unstage, does that mean with jj you would always have to remove them before pushing? I haven’t found an answer on the linked page. Side note: I really wish git had a way to mark commit has ‘no-push’ so they never leave your local…
Isn’t this just .gitignore? I feel like I’m missing something.