Hacker News new | past | comments | ask | show | jobs | submit login

A small correction...

`git branch [branchname]` creates a branch without switching to it.

`git checkout -b [branchname]` creates a branch and checks it out.

And `git reset --hard` will also discard changes. (Arguably, this is better than `git reset` discarding local changes, as it is more explicit.)




Your comment only makes the GPs point stronger.


I don't think so; I'm not much of a developer but I've used git productively for years and I've never had to run the commands CydeWeys listed.

The commands johnmaguire2013 listed are the ones usually recommended for beginners and I have found them easy to understand.

"git branch [name]" is for creating branches; it tells you if the branch already exists. Pretty easy to understand.

"git checkout [name]" is for checking out branches; it tells you if you're already on that branch.

You can run these sequentially and it works fine; there's no need for `git checkout -b [branchname]`.

I think there is sometimes some productivity porn involved in discussions of git, where people feel really strongly that everything should be doable in one line, and also be super intuitive. It's a bit like the difference between `mkdir foo && cd "$_"` on the command line, vs just doing mkdir and cd sequentially. IMO the latter is easier to understand, but some experienced folks seem to get upset that it requires typing the directory name twice.


Mm, I'm not sure I agree. The first correction shows that the command works as GP would have expected. The second command shows why checkout works too -- because it is checking out the branch (like the GP expected) in addition to creating a branch.

And I have already explained why `git reset --hard` makes more sense in my opinion.

I agree that Git can be hard to wrap your head around, and that the commands could be more intuitive. But Git is complex in large part because the underlying data structure can be tricky to reason about -- not because the UI on top of it is terrible.


There may be complexity under the hood (I don't know), but in my experience, even pretty advanced users employ a pretty straightforward mental model that's considerably simpler than the commands themselves are to use.


I disagree. I think the commands are intuitive and work perfectly for the system. It's very expressive, but it all makes sense once you've learned it.

git is a tool. Different tools take different amounts of time to master. People should probably spend some time formally learning git just as one would formally learn a programming language.


Other version control systems don't have this problem as much.


And where are they now? If you're not using git as source control at this point, I wouldn't even consider downloading your project.



Git succeeded in spite of its CLI, not because of it.


It's a good point: just because an entire product won out doesn't mean that every single one of its features was individually superior to its competitors. This is definitely not true for git.


That's roughly the same as saying that you won't eat the food prepared by a chef if they don't use your favorite brand of knife. You've diminished the value of your previous comment substantially with this one.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: