61–70 of 269 posts
Earlier quoted context omitted.
Isn’t this just .gitignore? I feel like I’m missing something.
That won't work for local changes to files that are legitimately committed in the repo. Like if you need to set your local database, or your own dev hostname in config, for example.
my initial reaction, half OT: Ooof, random "ASCII" (actually: Unicode) art & dev-chosen colors, my bane of the "modern" CLI applications. That drawing you like? Doesn't work for me, give me the raw output please. Those colors you love? Aside of red-green weakness being the most dominant factor, what you're really doing is trying to set things apart, connotating color with semantics as well. It's nice this works fine…
If not, then I have https://github.com/alrs/nofun
Earlier quoted context omitted.
Isn’t this just .gitignore? I feel like I’m missing something.
That won't work for local changes to files that are legitimately committed in the repo. Like if you need to set your local database, or your own dev hostname in config, for example.
If my local setup requires me to ignore changes in checked-in files, I usually find that I need to handle configuration more cleanly.
(I did work on a project that made use of git update-index - this was a terrible mistake and caused pain every time we needed to update the config file in the repository. Please never go down this route!)
my initial reaction, half OT: Ooof, random "ASCII" (actually: Unicode) art & dev-chosen colors, my bane of the "modern" CLI applications. That drawing you like? Doesn't work for me, give me the raw output please. Those colors you love? Aside of red-green weakness being the most dominant factor, what you're really doing is trying to set things apart, connotating color with semantics as well. It's nice this works fine…
I was curious about this as well, as I found the images in the README a bit hard to read. In fact the program itself seems to use quite sensible colours in my white-background terminal, and it also respects the NO_COLOR environment variable.
Nice 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,…
"working copy is automatically committed" seems like a good idea at first glance, but there are many situations where this is not a good idea: - when new artefact files are added and you have not yet added them to .gitignore, they'll be automatically committed - when you have added ignored files in one branch and switch to another branch, the files will still be in your working copy but not listed in your .gitignore…
> switch to another branch, the files will still be in your working copy but not listed in your .gitignore file
This is a failing of git, imo. There should be a .local.gitignore to somesuch, that is "added to" .gitignore. It's VERY common for me to have files that I want ignore, but are specific to me; they don't belong in the project's .gitignore. I know there are ways to do this, but all of them are clunky. There should be a simple, out of the box way to do it.
How does it handle very large repos and binary files? I want petabyte scale history and terabyte scale sparse clones.
Alternatively, why use this over Git? I read the differences but feel like I’m missing a higher level difference. What problems does this solve that Git/Hg don’t solve already? What was the inspiration for starting the project?
Earlier quoted context omitted.
> started as author's personal project and now author's full-time project at Google That's got to feel good!
Absolutely, good for the author. However, given the numerous examples of Google pulling the plug on nonessential projects, I don’t see this as strictly positive development.
Earlier 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…
> In git you would always leave the changes unstaged I do this too, but I quite frequently forget that I've done it and "git commit -am" and end up pushing my private changes anyway.
i have these 2 aliases assume = update-index --skip-worktree unassume = update-index --no-skip-worktree
"assume" as in "assume it's unchanged / not wanted"
which lets me say "git assume path/to/file" and then "unassume" it when/if i want to commit it.
The tool looks great; I have a hurdle to overcome with the name. I'm long accustomed to spelling it, in English, as Jujitsu. I've also seen Jiu-jitsu. "jutsu" is much less common, IME. Is there such thing as canonical Romanisation of Nipponese? I can deal with a project being "wrong" better than not knowing which of us is wrong.
As a Brazilian Jiu Jitsu practitioner, I cringe when I see it spelled any other way, but also I have to recognize that I only feel that way because I have more exposure to that specific martial art/spelling.