Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New in Git: switch and restore

banterly.net

Post reply on HN
Print view View original

421–430 of 550 posts

Re: New in Git: switch and restore

#421

Post by alkonaut »

notatoad wrote: post #417
alkonaut wrote: post #369

> 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 It's like they had a design meeting where they discussed this and said "so I propose switch -b newbranch to create and switch to a new branch" and the objection was "nah that would make it consistent with check…

i think they had a design meeting where they said "lets add some new commands to make git easier for newbies". carrying over flags whose abbreviated forms don't make any sense in the new context doesn't make anything easier for anybody. if you want to keep using the commands you have memorized, you can do that - just don't use switch or restore. the new commands are different, that's the point.

Probably. But choosing the wrong-but-consistent flag would have been easier to learn and remember. I don’t think anyone will consider different git commands as old/new, or core/porcelain or whatever it is. I just want semantical “delete” to have the same switch name, for example.

Re: New in Git: switch and restore

#422

Post by alkonaut »

eevilspock wrote: post #405
alkonaut wrote: post #369

> 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 It's like they had a design meeting where they discussed this and said "so I propose switch -b newbranch to create and switch to a new branch" and the objection was "nah that would make it consistent with check…

The purpose of `git switch` is to switch branches, and its normal argument is a branch ref. Thus -b for "branch" would be redundant and confusing. -c is for "create", i.e. create the branch that i want to switch to. The whole point of adding git switch and git restore is to come up with more user friendly porcelain. Otherwise we might as well stick with git checkout. git checkout is maximally consistent with git chec…

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? The problem here is obviously the choice made for checkout, not switch. But consistency is more important so it’s better to keep consistency than “correctness” here imo. This problem already happened in the past with -d (delete).

Re: New in Git: switch and restore

#423

Post by bawolff »

lisper wrote: post #94
hkopp wrote: post #49

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…

> Other than that, I recommend that people learn to use git properly. Sorry to be harsh here, but that is completely useless advice. It's a tautology. Of course people should learn to use git "properly". What's the alternative, that they should learn to use it improperly? Everyone should learn to use everything properly. It's like telling someone dealing with a crisis that they should "take appropriate action", as if…

> Of course people should learn to use git "properly". What's the alternative, that they should learn to use it improperly? Everyone should learn to use everything properly

No, its not. The alternative is not to.

Time is not free. Learning a tool properly is an investment. Sometimes that's worth it and sometimes its not. E.g. i would never advise anyone to take the time to learn dc properly.

Re: New in Git: switch and restore

#424

Post by schlupa »

jen20 wrote: post #149
cerved wrote: post #118

Earlier quoted context omitted.

we use it because it's blazing fast, stable and extremely versatile

I’d add another reason to that: we’re using Git because BitKeeper wasn’t free (as in beer) at the time for general purpose use. Had it been, we’d all be using BitKeeper instead.

Probably not. The free (as in speech) part of git is what made it usable for entities like google, Microsoft, github etc. If git had been released with the same license model of BitKeepr it NEVER would have taken off.

Re: New in Git: switch and restore

#425

Post by bendiksolheim »

alkonaut wrote: post #422
eevilspock wrote: post #405

Earlier quoted context omitted.

The purpose of `git switch` is to switch branches, and its normal argument is a branch ref. Thus -b for "branch" would be redundant and confusing. -c is for "create", i.e. create the branch that i want to switch to. The whole point of adding git switch and git restore is to come up with more user friendly porcelain. Otherwise we might as well stick with git checkout. git checkout is maximally consistent with git chec…

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? The problem here is obviously the choice made for checkout, not switch. But consistency is more important so it’s better to keep consistency than “correctness” here imo. This problem already happened in the past with -d (delete).

Which is better depends on what you want to achieve. In this case, the whole point is to make git easier to use as a tool. Carrying over ideas we already know are confusing would therefore be wrong in my opinion.

Re: New in Git: switch and restore

#426

Post by wutbrodo »

PaulDavisThe1st wrote: post #211
joseluis wrote: post #77

Earlier quoted context omitted.

the solution I believe would be to focus on creating simpler tools, and by that I mean tools with at least the same usefulness/as powerful as the ones we have now, but with much less cognitive burden, with better interoperability and composability by using simple standard data interchange formats.

If you really believe this, then I don't believe that you understand what the job of a powerful revision control system is. The "cognitive burden" of git comes as much from the tasks that it is occasionally required to make possible than anything else. If the only git commands you ever use are push, pull, commit and checkout then its a very simple system with very little cognitive burden. But one day, you may need to…

I generally agree with you that much of git's conceptual complexity is irreducible if you want to retain git's power. But there's plenty of examples of poor-quality and inconsistent porcelain that provide no extra power. Indeed, these "UI smells" mostly offer no benefit at all.

Note that we're specifically discussing the theoretical reason for git's usability woes. The costs of actually fixing them in git aren't trivial, of course.

Re: New in Git: switch and restore

#427

Post by schipplock »

agilob wrote: post #317
tsimionescu wrote: post #176

Earlier quoted context omitted.

You should have recommended Emacs Magit just to see the looks on everyone's faces.

Funny enough, one argument against cli git was 'vim' as commit text editor ;) Maybe emacs would convince them!

  EDITOR=joe git commit
:)

Re: New in Git: switch and restore

#428

Post by _6pvr »

lisper wrote: post #94
hkopp wrote: post #49

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…

> Other than that, I recommend that people learn to use git properly. Sorry to be harsh here, but that is completely useless advice. It's a tautology. Of course people should learn to use git "properly". What's the alternative, that they should learn to use it improperly? Everyone should learn to use everything properly. It's like telling someone dealing with a crisis that they should "take appropriate action", as if…

I've always found it interesting that Git gets a pass for its horrible UX by so many devs. The programming community wants to provide too many options for _everything_. If there's a tool you don't like, there are probably 10 other versions that do similar enough things that you can just switch. Devs are harshly critical of tools. And yet, with Git, the response just seems to be "if you don't like it you must just not _get it_." Which, I guess is fair, but I don't particularly understand why everyone has to "get it"? Why can't we expect a tool that's used by so many be intuitive? Or at least, _more_ intuitive? It feels a bit like hazing at this point. The post recently about `git undo` was great, I think, because of the frequency with which users encounter surprising and unintended behavior.

It continues to be kind of frustrating to me. It feels like a tool that should be wrapped in something else and never even brought up to 99% of users. A half finished idea on productivity and team centric version control (to get ahead of comments: I know it's not designed to be that, but that's how it's very frequently used).

Re: New in Git: switch and restore

#429

Post by chalst »

samatman wrote: post #302
chris_j wrote: post #292

Earlier quoted context omitted.

What would you recommend using instead of git? (Myself, I've been heard complaining that git is overly complex, but the source code control systems that I used to use before git include Subversion, CVS and various Rational products and I have no desire to go back to any of them.)

I can't recommend pijul, but I can recommend keeping an eye on it. Pierre-Étienne Meunier is a ferociously smart guy, and he's convinced me that patches are the correct way to build a VCS, rather than snapshots. I catch up on a forum a few times a year, asking myself if it's ready for me to switch a repo or two over and see how it goes. So far I have to answer no, but I'm hoping it's just a matter of time.

Pijul is probably OK to use now:

https://pijul.org/posts/2021-06-28-two-changes/

Like a new filesystem, you should have a backup system in place if you use this, but the system is being well tested.

Re: New in Git: switch and restore

#430

Post by aniforprez »

tryingtogetback wrote: post #213
aniforprez wrote: post #193

Earlier quoted context omitted.

Your analogy is completely awful The janitor knows nothing about dentistry. The git GUI knows plenty about it and the devs make it their job to know it too. A janitor is not an abstraction, he's a liability. If a GUI abstraction helps me get the job done faster, I really don't see the problem. Plus almost every one of them fully state the commands being used to perform every action and have logs you can parse. I used…

You are contradicting yourself and making my point for me. janitor is an abstraction (you trust a janitor to operate with a professional tool for you) and you are completely right, git GUIs (just like a janitor) are a liability.

Your analogy is awful because there literally is a better analogue. A dental assistant. Someone who actually knows dentistry and can help with some of the simpler tasks to leave the dentist to concentrate on the actual surgery. You basically tried to fit a square hole in a round peg with your "analogy" to make your terrible point
Post reply on HN