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

221–230 of 280 posts

Re: Oh shit, git (2016)

#221

Post by sanderjd »

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…

Yep, mercurial really is better, but it is also noticeably slower. I used git for about a decade, and now use hg at my job. Recently, I used used git again while playing around with something over a weekend. I instantly remembered why I loved it so much. There is really something to be said for commands resolving practically before you have noticed you pressed enter. I wonder if this is inherent or accidental; I don't know the mercurial data model well enough to understand why it would be necessarily laggier.

Re: Oh shit, git (2016)

#222

Post by scarejunba »

otikik wrote: post #116
scarejunba wrote: post #18

Honest to god, I don't know how people who find `git` hard to use manage to write code. Everyone on the Internet acts like the concepts are impossible to grasp and it's like really easy to grok. Honestly, it faded into the background of code from the beginning. I mean, I know "Forward-port local commits to the updated upstream head" means nothing to anyone not already familiar with `git rebase` but a practical master…

Confess. You are the Git Hobgoblin masquerading as a human programmer. http://stevelosh.com/blog/2013/04/git-koans/#the-hobgoblin

I refuse. I object to “git is hard”. I do not object to “the UX can be improved, perhaps significantly”. Other things that are easy but could have improved UX:

* Bart turnstiles: the green lit-up arrow doesn’t mean you can use the turnstile with your card. Only if that arrow is present and the Clipper reader has a green light on it can you use it. Not hard, really.

* Doors that you should push but have a handle: the presence of the handle implies a pull and yet you have to push. Hard? No.

* Applications which use a floppy disk icon for save. Not hard at all.

Honestly, I think the UI is like any tool. You learn it in a day and through use it gets so familiar you don’t even think about it. But many have complained about this and UIs are harder to evaluate, so I can easily admit I’m wrong here. The difficulty, though, that’s overstated. The absolute ease with which it came to me and to nearly everyone I know puts the lie to that.

Re: Oh shit, git (2016)

#223

Post by darkpuma »

ethbro wrote: post #150
darkpuma wrote: post #43

Earlier quoted context omitted.

Hg and git have near feature parity, so I don't really lament Hg's loss so much. Sure Hg's CLI is a little bit better, but beyond that it never really offered any really compelling features over git. Mercurial and git is like Honda and Toyota; maybe one is a bit nicer than the other, but they're both offering you more or less the same thing. Fossil is another matter. Fossil defies pithy car analogies. Integrating the…

> Mercurial and git is like Honda and Toyota; maybe one is a bit nicer than the other, but they're both offering you more or less the same thing. As a car guy, Honda makes cars. Toyota makes appliances for people who hate driving.

My personal preference is for Honda as well, but when you sit down in the drivers seat and survey what is in front of you in a Honda or a Toyota, you'll find they have more or less the same things. Perhaps Hondas being set up to be more agreeable to "car guys" is similar to the CLI of Hg not being so obtuse, but both are still nevertheless capable of more or less the same feats. They'll both see you through your commute and either is a bad choice for off-roading.

Re: Oh shit, git (2016)

#224

Post by gatherhunterer »

dwaltrip wrote: post #41

Git is pretty nice, but I'm sure there is something much better waiting to he invented. The CLI in particular could use a ton of improvements. And I feel it in my bones that there is a revolutionary GUI waiting to be invented. Why can't I drag a commit or set of commits from one branch to another? With safe, easy undo (reflog doesn't count) and super smooth conflict resolution? Etc etc. And of course there is the int…

> Why can't I drag a commit or set of commits from one branch to another?

GitKraken might be for you, there is a nice drag-and-drop feature demonstration at https://www.gitkraken.com/git-client.

I don't think you can drag commits because a commit itself is a snapshot that describes changes to a branch so it is the branch itself that can be merged, rebased, pushed, etc. by drag-and-drop.

Re: Oh shit, git (2016)

#225

Post by darkpuma »

bunderbunder wrote: post #191
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…

> git, ugly as it is, reflects the underlying data model. Once you understand that data model... This is, like, the very definition of bad/sloppy UX.

No, I strongly disagree. Exposing the datamodel can be part of an excellent user experience if your target audience are programmers, as is the case with git. Where git goes wrong is numerous commands that do numerous very different things if given different flags. That has nothing to do with the underlying datamodel being exposed; it's just sloppy planning and design. That part is terrible UX.

Re: Oh shit, git (2016)

#226

Post by scarejunba »

tluyben2 wrote: post #61
scarejunba wrote: post #18

Honest to god, I don't know how people who find `git` hard to use manage to write code. Everyone on the Internet acts like the concepts are impossible to grasp and it's like really easy to grok. Honestly, it faded into the background of code from the beginning. I mean, I know "Forward-port local commits to the updated upstream head" means nothing to anyone not already familiar with `git rebase` but a practical master…

I was thinking if I would post what you did it would get downvoted but yeah, if you find git hard how or why are you writing code? That is surely a lot harder. Not sure why it is downvoted as sure it might not be a popular opinion but it seems to hold...

Thank you for posting. It helps to know that others, too, haven’t had this uphill slog just to use it. It just faded into the background right from the start.

Re: Oh shit, git (2016)

#227

Post by scarejunba »

darkpuma wrote: post #44
scarejunba wrote: post #32

Earlier quoted context omitted.

I'm not the hot shot. The hot shots are all the kids from Berkeley and Stanford who figure this shit out as interns while supposedly fully-trained engineers with all the knowledge of data structures that should come with that think this shit is too hard. I think I'd be completely unsurprised to see an intern successfully use `rerere` on a longer project of theirs.

I know of teenagers who happily use git because nobody ever told them they were supposed to consider it hard.

This is exactly what I’ve seen. Thank you for validating that viewpoint. Without being told they’re going to find it hard, they just rapidly build a model of how to interact with the tool and how it improves their life.

Re: Oh shit, git (2016)

#228

Post by recursive »

ethbro wrote: post #150
darkpuma wrote: post #43

Earlier quoted context omitted.

Hg and git have near feature parity, so I don't really lament Hg's loss so much. Sure Hg's CLI is a little bit better, but beyond that it never really offered any really compelling features over git. Mercurial and git is like Honda and Toyota; maybe one is a bit nicer than the other, but they're both offering you more or less the same thing. Fossil is another matter. Fossil defies pithy car analogies. Integrating the…

> Mercurial and git is like Honda and Toyota; maybe one is a bit nicer than the other, but they're both offering you more or less the same thing. As a car guy, Honda makes cars. Toyota makes appliances for people who hate driving.

I hate (or at least am annoyed by) dealing with source control, although I acknowledge the need for it.

So does the analogy still fit? And which one is better for people that are merely putting up with the necessity for source control rather than enthusiasts?

Re: Oh shit, git (2016)

#229

Post by jsilence »

jrochkind1 wrote: post #144
dzdt wrote: post #115

Am I the only one who reads "reflog" as "re-flog", that is, to be painfully whipped again?

I knew about it for at least a year thinking it was "re-flog", and just considering it mysterious why they would have called it that. (You do often use it for "re"-doing things, maybe it's got something to do with that?) Hey, it was (and is) hardly the only mystery to me in git UI. Then like a year on I suddenly realized Ohhhhh it's ref-log, that makes a lot more sense!

.oO( the beatings continue until morale improves! )

Re: Oh shit, git (2016)

#230

Post by erik_seaberg »

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 tried learning hg and arrived at http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me... which is a crazy complicated answer to what should be the most important question.

There's just something about git branches and refs that makes sense to me. The CLI commands are a mess, of course—why can "reset" do everything?

Post reply on HN