211–220 of 269 posts
Earlier quoted context omitted.
Why do you want such big files in a git repo?
How about why not? The only reason it's not done is because git doesn't support it.
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…
It makes fewer errors than I do. Besides forgetting syntax, fat fingering is a thing.
Conflict resolution is faster, easier, and less error-prone.
Pretty typical sorts of efficiency gains that IDEs can give.
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…
It's not that it's hard to believe, I've seen enough discussion on this very topic to know many people (at least on HN) seem to prefer the CLI for VCS interaction. I'm merely wondering why people seem to prefer a lower-level, separate tool to a higher-level, integrated one. To me it seems similar to writing your Makefile by hand vs. using automake. The same as you, I don't want to dismiss anyone's tooling. Just curio…
Earlier quoted context omitted.
If I could enforce one thing, it would be to REQUIRE partial commits for everything from an UI. I can't tell you the amount of commits I have seen that need to be cleaned up from spare debugging statements to vendor files to things that need to be added into the git ignore. The other thing would be to make sure people understand what things like 'squash' and 'rebase' to and how they effect the tree. Also to explain i…
> from an UI Just a really quick aside... Do you... say "oooey" instead of "you eye" when reading "UI"?
Earlier quoted context omitted.
I almost always do "git add -p", "git commit". "add -p" is great for showing you all the chunks of code you've written one-by-one and then you do "y" or "n" for whether you're adding them. Doing it like this means that you are reviewing what you've changed as a final check that you haven't left a debug line in, or forgotten part of what you meant to do. It's also a natural way of splitting up what you've done into tw…
The analogous command here is `jj split -i`, which interactively splits the current commit (which is your working copy).
Also learning about progress git workflows though, so that's cool.
Earlier quoted context omitted.
Ooh, that's me! As in the comment, please don't do this. It's been a while since I worked at a place doing this, and I'm on my phone, so some details may be fuzzy or wrong, but when I was figuring all this out, I remember this SO comment being really helpful: https://stackoverflow.com/a/23806990 Basically, there's two different APIs, and neither of them are designed for ignoring config files (but both of them happen…
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…
Earlier quoted context omitted.
It's a horrible name to pronounce for many non-English speakers.
Did you know that the English way to pronounce "jujutsu" isn't how the Japanese pronounce it? The Japanese way to pronounce it could actually be a lot easier for many non-English speakers (I'd anyway argue it's a common enough word that people are familiar enough with it to pronounce it in a way that's comfortable to them).
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 two types of people who understand git on my team. People who use the CLI and people who don't understand git and just start clicking buttons
I learnt how to use git years before I learnt to use the git CLI.
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…
I 100% agree with you that a GUI is by far the sanest way to do most git operations (I have yet to find an interactive rebase GUI that is better than a text editor). But if you just pick a random GUI it's probably going to be not very good.
Good GUIs I have discovered:
* GitX (Mac only) * GitExtensions (Windows only I think) * The VSCode Git Graph extension is basic but decent. Unfortunately it seems to have been abandoned.
I have tried many many others and they all sort of work but don't present things in an easy to follow way.