221–230 of 269 posts
I 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…
Earlier quoted context omitted.
For a long time I have been wishing that Git had a capability of "track this file locally, but don't transfer it when pushing or cloning". Such files would be listed using the same syntax as .gitignore, but in a different file, say .gitlocal or something. Git kind of has some "local tracking" already: if I am not mistaken, lightweight tags behave like this. It would be cool if it could track files in the same way. Un…
this may not help you, but JetBrains IDEs have "local history" which addresses many of those concerns, including applying tags to meaningful points in time: https://www.jetbrains.com/help/idea/local-history.html
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.
There are multiple romanisation systems for Japanese, but the most common one is Hepburn. In Japan, Kunrei-shiki is sometimes used (especially by the government), which is designed with Japanese speakers in mind (vs Hepburn which was designed with English speakers in mind). It's jujutsu in both, but there are varying ways of representing the long vowel on the first "u" -- either omitting it (jujutsu), using a macron…
Earlier quoted context omitted.
There are multiple romanisation systems for Japanese, but the most common one is Hepburn. In Japan, Kunrei-shiki is sometimes used (especially by the government), which is designed with Japanese speakers in mind (vs Hepburn which was designed with English speakers in mind). It's jujutsu in both, but there are varying ways of representing the long vowel on the first "u" -- either omitting it (jujutsu), using a macron…
The base assumption, though, is that we're talking about 柔術 (with a long u), not 呪術 (without a long u). Without a clarification from the author, it's hard to tell which one it's supposed to be.
The first kanji in 呪術 means curse, so while "sorcery" could be a cool name for a software project in English, a Japanese speaker would probably have apprehensions about using 呪術.
Earlier quoted context omitted.
Because I have always and will always prefer to interact with my VCS on the command-line. 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 eas…
I, on the other hand, have always and will always prefer to interact with my VCS via the editor-integrated plugin with GUI. 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), and I can use all my familiar plugins from the extension marketplace to work with it. Yes, when I switch my favourite editor I'll have to relearn most of the pa…
The TUI feature?
I 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…
Because I have always and will always prefer to interact with my VCS on the command-line. 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 eas…
And you don't have to learn about each editor, just learn about one
And those command line skills can just be used in those advanced cases, that doesn't mean the 90% of the time you have to have worse experience
It's not hard to believe, it's just the arguments don't square
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…
> 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. I appreciate that there are times when this has to be in the middle of an otherwise committed file, but it's worth avoiding that if at all possible and putting the locally-changed bit in a different file because, as others have pointed out, this is error prone. It feels…
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…
> my bane of "modern" CLI applications
Ok boomer, I guess you're also a Rust hater too - because I love that every last CLI written in Rust is not garbage because clap is so good and so ubiquitous
All the colors and unicode graph can be configured and disabled through config and CLI flags, and the default pager is less which supports NO_COLOR and piping and everything else that less does.
It literally has an extensive template system as one of the features to make the log output ANYTHING you would want:
adjust some colors that you hate? sure (also there's a config for color names that are used in templates, for colorblind or contrast adjustments etc)
add/remove/adjust some info (that you hate)? sure
just list full commit ids to be machine-readable that match some revset? - absolutely
Man, why do I feel so second-hand embarassed from reading this dumb ignorant reply, lol