521–530 of 550 posts
Another difference is that with git checkout you can create and switch to the new branch in one command using the -b flag: git checkout -b new_branch You can do the same with the new one, but the flag is -c: git switch -c new_branch A good example why developers should not try to be designers. Even of talking about "API/CLI design.
Another difference is that with git checkout you can create and switch to the new branch in one command using the -b flag: git checkout -b new_branch You can do the same with the new one, but the flag is -c: git switch -c new_branch A good example why developers should not try to be designers. Even of talking about "API/CLI design.
Apple and GNOME are even better examples of why designers should not try to be designers. Now what options do we have left?
KDE, git, and FreePascal / Lazarus.
Earlier quoted context omitted.
> How does -b mean “create” in checkout? I get that it means “branch” but why is “branch” what I use to create a new one? Because you can "checkout" other stuff too, not just branches. > But consistency is more important so it’s better to keep consistency than “correctness” here imo. Huh? I thought the whole point of these new commands was to try and fix the old illogical command line interface. Since one of the main…
Yes - if this is meant to be a whole new set of commands which are internally consistent and can be used without using the others, then it makes sense to do it right. But is that the case? Won’t this just be used in addition to the old commands (except checkout)? The worst case would be adding commands that attempt to fix an UX but which don’t replace it, creating two separate UXes you must use at the same time. Anyo…
Dunno. (Elsewhere in this thread, the guy who built them reported that he isn't on the git dev team any more, so perhaps not too promising.)
> Won’t this just be used in addition to the old commands (except checkout)?
That's still a massive improvement, since checkout was arguably the main culprit. Also, it was never the case that you'd have to replace all git commands to achieve consistency: Many (hopefully most) already had consistent naming of arguments and options. So make your new ones compatible with the largest set of internally-consistent ones already present, and you only need to replace a minority. (Worst case, if all N were incompatible with each other, you'd have to replace N-1 -- but you could still keep one. :-)
Then there's also usage frequency to consider. Given that checkout is the command most inconsistent with others, often inconsistent even with itself, and among the very most used ones overall -- almost certainly, in my estimation, the most used of the candidates for replacement -- I'd say even if nothing more comes of this, it's a huge net win.
Also note that it's not a case of "two separate UXes you must use at the same time": git checkout is still there; no piece of the "old control panel" has -- AFAIK, or has any? -- been disabled or removed.
Earlier quoted context omitted.
If it truly hasn't been fixed for years, then either the people involved haven't noticed or don't care. If the former, filing an issue is helpful. If not, filing a patch may not get anything fixed either.
It is more likely that "the people involved" are working on other things or just don't share your concern. Filing a ticket can be helpful, but a pull request is usually preferred times 10,000. You are right, it is also possible that a change may mot get merged... In which case you've added the feature so the software is more useful to you anyway. Everyone wins.
Earlier quoted context omitted.
You don't find it interesting you are armchair quarterbacking the most successful VCS software in existence, disregarding that it evolved, that its API reflects that? You assume there is no design process. You're making a lot of assumptions and simplifications. Concern or worry even "fear" are fine, but your language has been more judgmental than concern. There are plenty of git wrappers that offer a cleaner API; you…
> You don't find it interesting you are armchair quarterbacking This is hacker news. It’s basically a few thousand armchairs. Welcome. > You assume there is no design process. I’m not saying that. I was just a few minutes ago explaining how I have tried to see traces of it. From the software itself there aren’t any obvious signs of (long term) UX design. > the most successful VCS software in existence Lots of stuff i…
Uh... Git was created by the guy who created Linux.
Initially to help manage distributed Linux dev. Not forced on anyone other than Linux devs. Not dominant through nefarious business practices like MS Windows, but because it spread *organically* overtaking other "well designed" systems. People voted with their feet.
Earlier quoted context omitted.
> I am not paid to know GIT inside out. I am paid to deliver and fix code and to not step on other people's feet. Your argument is still the same as the other git detractors, and is still wrong. It _is_ part of your job, it _is_ part of delivering and fixing code. It's the same as anything else you're using. It may be a larger surface area that you're exposed to, but it's no different from CI/CD, build systems or som…
The issue here is GIT is way more complicated to learn, because it has 10.000 options that might do what you want to do or do something else entirely. Imagine your deployment pipeline required you to manually craft TCP packages to send to your machines to deploy code...would you still say "it _is_ part of your job, it _is_ part of delivering and fixing code", or would you say "that is stupid"? With GIT, you are spend…
You're doing it really really wrong if you spend more time learning git than writing your code. Even with its bad UX it's just not that hard.
My git productivity hack is `git diff --color-words`. Instead of showing the line-by-line diff, it shows only the words that changed. Especially useful if you have long sentences where only a comma changed or some other typo. With git diff, the two lines are shown, with --color-words, only the changed symbol is highlighted. The option --color-words also works with git show. I even made aliases for them: git cshow and…
I highly suggest delta[1] for viewing diffs on the command line. It pretty much replicates GitHub's diff rendering, and is quite configurable. [1]: https://github.com/dandavison/delta
Earlier quoted context omitted.
> You don't find it interesting you are armchair quarterbacking This is hacker news. It’s basically a few thousand armchairs. Welcome. > You assume there is no design process. I’m not saying that. I was just a few minutes ago explaining how I have tried to see traces of it. From the software itself there aren’t any obvious signs of (long term) UX design. > the most successful VCS software in existence Lots of stuff i…
> I do enjoy pissing on things that look or feel Unix-y Uh... Git was created by the guy who created Linux. Initially to help manage distributed Linux dev. Not forced on anyone other than Linux devs. Not dominant through nefarious business practices like MS Windows, but because it spread *organically* overtaking other "well designed" systems. People voted with their feet.
Earlier quoted context omitted.
Yes - if this is meant to be a whole new set of commands which are internally consistent and can be used without using the others, then it makes sense to do it right. But is that the case? Won’t this just be used in addition to the old commands (except checkout)? The worst case would be adding commands that attempt to fix an UX but which don’t replace it, creating two separate UXes you must use at the same time. Anyo…
> But is that the case? Dunno. (Elsewhere in this thread, the guy who built them reported that he isn't on the git dev team any more, so perhaps not too promising.) > Won’t this just be used in addition to the old commands (except checkout)? That's still a massive improvement, since checkout was arguably the main culprit. Also, it was never the case that you'd have to replace all git commands to achieve consistency:…