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

Oh shit, git (2016)

ohshitgit.com

Post reply on HN
Print view View original

181–190 of 280 posts

Re: Oh shit, git (2016)

#181

Post by fouronnes3 »

andrewla wrote: post #172
jchw wrote: post #35

Earlier quoted context omitted.

I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. That’s not all it has going for it either. Mercurial has a concept of commit stages to make history rewriting safer. It has a commit model that enables you to work on and manipulate branches of commits seamlessly, without needing named branches. It has not just a tree of commits but also each commit trac…

> I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. I think that's true if you're coming from something like Perforce or Subversion and have some notion of what the expectations are around those environments. It's much easier to translate that model into Mercurial commands. But in the end it's deceptive; git, ugly as it is, reflects the underlying data…

Even if you understand the data model perfectly, git still has terrible UX. reset can do 3 different things, a "remote" can mean 3 different things depending on context... I could go on all day. Just the fact that there are parodies of git man pages should drive the point home. (Disclaimer: I love git). Oh and what the hell is 'git rerere' anyway?

Re: Oh shit, git (2016)

#182

Post by swish_bob »

rusk wrote: post #127
mehrdadn wrote: post #123

Earlier quoted context omitted.

I'm not being hyperbolic or giving a trivial example (whatever that's supposed to mean), I was completely seriously pointing out that people used to apply your exact same victim-blaming logic to that same scenario until others finally made them come to their senses and realize that, just because the user happens to type in a command that tells the computer to shoot him in the face, that doesn't necessarily mean the c…

A "trivial example" is where you demonstrate a concept using a simplified or trivial scenario. It's quite a common term, and I didn't mean it as a put-down. "victime-blaming", "shoot in the face" .. I feel are fairly extreme terms to describe what's happening here. The scenario you've concocted is really only one that could occur where you didn't know what you were doing and Git (or the command line) aren't really th…

It's not a concocted scenario, the cli command in question explicitly has a property that defaults to preventing it from doing what it should do, unless you override the property. Explicitly because it's so destructive when you do it by mistake.

Re: Oh shit, git (2016)

#183

Post by cesarb »

dahart wrote: post #175
batisteo wrote: post #80

Earlier quoted context omitted.

> Git is pretty nice, but I'm sure there is something much better waiting to he invented. It is indeed being invented. It’s called Pijul: http://pijul.org/ This tool is based on strong mathematical theory of patches, instead of snapshot/commit-based. It seems simpler to reason with, but we’d have to unlearn a lot from Git. It’s not suitable for big projects yet, but it’s already used by Pijul itself and other Rust co…

> This tool is based on strong mathematical theory of patches Is this a good thing? What practical problems does a strong mathematical theory of patches solve that git doesn’t? And what’s the difference between a commit and a patch? Aren’t git commits stored as patches? I’m a math lover, but my gut reaction to that idea is that it sounds off-putting. I don’t mean that as a judgement or insult; I’m admitting my own as…

> Aren’t git commits stored as patches?

No, they aren't, git commits are stored as snapshots. Each git commit has one tree, which is a snapshot of the state after the commit; zero or more parent commits; a pair of authors with corresponding timestamps; a commit message; and nothing more. Any patch you see in git is an illusion, made by comparing the commit's tree with the parent commit's tree.

Re: Oh shit, git (2016)

#185

Post by MikusR »

jchw wrote: post #35
_7fvc wrote: post #20

Reading this article, I realize that I'm old now. I still remember wrestling with cvs, svn. Merge, branch were slow and even more challenging. It was much easier to mess up and so difficult to rewind. When I first learned git, I thought it's pretty neat. It solves merge, branch, rewind problems. Git is one of the things in life that doesn't work like the way we think. But it turns out to be a better way.

I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. That’s not all it has going for it either. Mercurial has a concept of commit stages to make history rewriting safer. It has a commit model that enables you to work on and manipulate branches of commits seamlessly, without needing named branches. It has not just a tree of commits but also each commit trac…

When i started using version control for my plain text notes, I initially settled on Mercurial (because of it's supposed better support for Windows), but turns out it doesn't support unicode filenames while git does. So I went with git.

Re: Oh shit, git (2016)

#186

Post by otabdeveloper1 »

jchw wrote: post #35
_7fvc wrote: post #20

Reading this article, I realize that I'm old now. I still remember wrestling with cvs, svn. Merge, branch were slow and even more challenging. It was much easier to mess up and so difficult to rewind. When I first learned git, I thought it's pretty neat. It solves merge, branch, rewind problems. Git is one of the things in life that doesn't work like the way we think. But it turns out to be a better way.

I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. That’s not all it has going for it either. Mercurial has a concept of commit stages to make history rewriting safer. It has a commit model that enables you to work on and manipulate branches of commits seamlessly, without needing named branches. It has not just a tree of commits but also each commit trac…

> The commands are more uniform and predictable.

Git won because it was a) unopinionated and b) powerful enough to support arbitrary workflows for any enterprise.

For the enterprise, being 'uniform and predictable' is way, way, way down lower on the list of important criteria in version control. (And in fact may even be a negative, due to the weird legacy workflows many enterprises have.)

Re: Oh shit, git (2016)

#187

Post by sirsuki »

crispyambulance wrote: post #130
teekert wrote: post #53

Earlier quoted context omitted.

Git is ugly and daunting when you start with it, but as you get to know it you start to appreciate it's beauty and elegance and it will work for you. Actually I find this with many programming concepts.

Git is neither beautiful nor elegant. It survives because it does the job and a critical mass of people has miraculously brought it to prominence. What I will NEVER be able to understand is WHY the commands are so fucked-up, inconsistent and counter-intuitive. It doesn't have to be that way. If git feels comfortable, it's only because you've crashed and burned it so many times or suffered though countless google sear…

The reason "the commands are so [messed]-up, inconsistent and counter-intuitive" is most likely that you expect the commands to represent your mental model of the system when in fact they represent the mental model of the system designers.

I once felt it was weird till I dove in and looked at the underlying data model. Then It struck me and all the awkwardness evaporated and the commands actually make sense to me now.

Re: Oh shit, git (2016)

#188

Post by rjzzleep »

andrewla wrote: post #172
jchw wrote: post #35

Earlier quoted context omitted.

I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. That’s not all it has going for it either. Mercurial has a concept of commit stages to make history rewriting safer. It has a commit model that enables you to work on and manipulate branches of commits seamlessly, without needing named branches. It has not just a tree of commits but also each commit trac…

> I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. I think that's true if you're coming from something like Perforce or Subversion and have some notion of what the expectations are around those environments. It's much easier to translate that model into Mercurial commands. But in the end it's deceptive; git, ugly as it is, reflects the underlying data…

I don't get that argument at all. I came from svn, used cvs and ss and I think I even tried to use Perforce at some point.

I don't see how people consider mercurial "easier", "the winner" or whatever.

I think it's like languages: if you're a french speaker and you translate everything into your native tongue while learning, then of course you won't ever get past roman languages. It's just different.

`git add -p` is my absolute favorite command ever. `tig` is just awesome. The gui clients are so beautiful and take away all the so called uglyness nowadays, though I just can't find myself using anything over git add -p. Nothing in mercurials commandline ever came close to these two. But yeah tig isn't really part of git but at the same time it's been around for so long it might as well be.

Re: Oh shit, git (2016)

#189

Post by fouronnes3 »

bicolao wrote: post #97
noname120 wrote: post #94

Earlier quoted context omitted.

Even after years of Git usage, `git reset --soft -- file`, `git reset --mixed -- file`, BUT `git checkout file` instead of `git reset --hard -- file` is ugly and symptomatic of Git's lackluster UX.

This particular pattern should be fixed in a future git (hopefully). There's a new command that supports all these git restore --staged file # reset the index from HEAD git restore --worktree file # reset the worktree from the index git restore --source=HEAD --staged --worktree file # reset both the index and worktree from HEAD Still in development [1] so if you think something can be improved, I'd love to hear it. […

Two things I don't like in your examples:

First, the default source changes depending on the target. In my opinion it would be more intuitive and simple if the default source is always HEAD. The documentation for --source in your link probably makes sense for a git developer, but not at all for a user. (Especially the part about its default value if absent).

Second, rename "--staged" to "--index".

So in summary, to update your examples, how about:

git restore --index file # reset the index from HEAD

git restore --worktree file # reset the worktree from HEAD

git restore --worktree --source=index file # reset the worktree from the index

git restore --index --worktree file # reset both the index and worktree from HEAD

git restore file # reset the worktree from HEAD

Re: Oh shit, git (2016)

#190

Post by jcranmer »

rjzzleep wrote: post #188
andrewla wrote: post #172

Earlier quoted context omitted.

> I’m torn. Practically Mercurial feels like it should be the winner. The commands are more uniform and predictable. I think that's true if you're coming from something like Perforce or Subversion and have some notion of what the expectations are around those environments. It's much easier to translate that model into Mercurial commands. But in the end it's deceptive; git, ugly as it is, reflects the underlying data…

I don't get that argument at all. I came from svn, used cvs and ss and I think I even tried to use Perforce at some point. I don't see how people consider mercurial "easier", "the winner" or whatever. I think it's like languages: if you're a french speaker and you translate everything into your native tongue while learning, then of course you won't ever get past roman languages. It's just different. `git add -p` is m…

The man page for git reset states in its first paragraph:

> In the first and second form, copy entries from to the index. In the third form, set the current branch head (HEAD) to , optionally modifying index and working tree to match.

When your documentation starts by saying (in effect) "this command does several different things", that should be a very strong sign that your command UX has some issues.

Post reply on HN