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

191–200 of 280 posts

Re: Oh shit, git (2016)

#191

Post by bunderbunder »

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…

> 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.

Re: Oh shit, git (2016)

#192

Post by JohnFen »

_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 agree. I still have to use svn in my workplace, but I use git for my own stuff. When things go wrong, I find it easier to fix it with git than svn.

Re: Oh shit, git (2016)

#193

Post by Matumio »

bloopernova wrote: post #170
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.

Has there been any efforts to add a wrapper around git's commands to make a more friendly command line UI? I've tried maybe 3 different GUIs for git and none of them really seemed to help that much. However my usage of git is pretty basic, with branches and tags being about as complex as I get.

There have been many attempts. I liked easygit a lot (seems to be unmaintained now: https://people.gnome.org/~newren/eg/documentation/). It had really nice docu. It took me a while to memorize all the native git replacements for `eg revert`. Gitless looks like it could fit your needs (https://gitless.com/).

The problem is, in the end, you'll still need to know the original git commands with all their quirks in addition to the easier commands, because that's what you'll find on stackoverflow or when asking colleagues or inside of error messages. And those command names will either clash with the names used in plain git or are different partially-overlapping concepts (`git reset` is the worst offender here). So eventually you'll need to memorize twice as many things.

Re: Oh shit, git (2016)

#194

Post by systemBuilder »

Git performs like what it is : a piece of code created by debugging a blank sheet of paper. I can detect almost no philosophy and no simplifying assumptions. The thought that you need 60+ commands (the current size of my git cheat sheet, including all the bizarre argument incantations which seem customized for all 100+ possible mistakes in git) to get through the day is an abomination. I prefer perforce which requires less than 20 commands. The only reason people use git is because, Linus.

Like no good program, ever, to use git you have to understand all the compromises and all the internals of its data structures. What a joke.

Re: Oh shit, git (2016)

#196

Post by lalaithion »

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 dunno, I recently switched from ~4 years of using git to mercurial, and I am finding mercurial massively easier to use.

Re: Oh shit, git (2016)

#197

Post by JohnFen »

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.

Perhaps, but speaking personally, that doesn't matter much to me. What matters to me is how much easier a tool makes my job, and of all the version control systems I've used, git is easily the winner.

Re: Oh shit, git (2016)

#198

Post by pseudalopex »

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…

Mercurial had "hg record" since 2007[1] and "hg crecord" since 2008[2]. Now you would use "hg commit -i".

[1] https://www.mercurial-scm.org/wiki/RecordExtension?action=in...

[2] https://www.mercurial-scm.org/wiki/CrecordExtension?action=i...

Re: Oh shit, git (2016)

#199

Post by JohnFen »

masklinn wrote: post #129
rusk wrote: post #103

Earlier quoted context omitted.

Hence the name I guess ... yeah it's ugly and annoying but you're stuck with it because it's great. Kind of like Linus himself I guess ... I wonder if that's the joke.

> you're stuck with it because it's great. We're stuck with it because of network effects. Git is absolutely not great .

I think git is great. But that might only be because all the other version control systems I've used are worse...

Re: Oh shit, git (2016)

#200

Post by _pmf_ »

mehrdadn wrote: post #63
_pmf_ wrote: post #34

I don't get this "afraid of losing something" mindset at all. In fifteen years, I've "lost" some minor changes maybe 3 or 4 times, and this was mostly with SVN, which does not have the safeguards that Git has. The only thing that I am moderately afraid of is pushing to the wrong remote branch.

> I don't get this "afraid of losing something" mindset at all. In fifteen years, I've "lost" some minor changes maybe 3 or 4 times, and this was mostly with SVN, which does not have the safeguards that Git has. The only thing that I am moderately afraid of is pushing to the wrong remote branch. I can lose something for you in 2 seconds in git. Have fun e.g. recovering from this: $ git init $ mkdir -p widget && echo…

Apparently I'm warned when I do this using SmartGit; if you are unable to safely use the CLI tool, maybe you should switch to a safer tool and leave the CLI tools to power users?
Post reply on HN