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

141–150 of 280 posts

Re: Oh shit, git (2016)

#141

Post by xelxebar »

gpvos wrote: post #135

One thing that I had been looking for for a long time, but never could find, was a description of the several syntaxes you can use to refer to specific commits. Lots of git tutorials use these magic incantations, but none point you to this crucial bit of explanation. Recently I discovered that it is found under "git help revisions".

Or just gitrevisions(7). The manpage for git(1) mentions this under the section SYMBOLIC IDENTIFIERS. Not that that's the most obvious place to look, but if you rtfm the obvious stuff, you should stumble upon these gems naturally.

It's worth scrounging through git(1) anyway; it mentions several other manpages for things like recommended workflows, the basic structure of the .git/ directory, not to mention gittutorial(7).

Re: Oh shit, git (2016)

#142

Post by jrochkind1 »

avar wrote: post #105
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…

> Mercurial feels like it should be the winner. The commands are more uniform and predictable. Keith Packard's "Repository Formats Matter" post nicely captures how meaningless it is to focus on this sort of thing in the long term: https://keithp.com/blogs/Repository_Formats_Matter/ I.e. yes Git has some UI issues, but those are fixable, whereas e.g. Subversion's UI was way better than Git in the early days, but its r…

> I.e. yes Git has some UI issues, but those are fixable

In theory, yes. However, a decade on an I'm not sure any UI issues have been fixed?

It turns out 'legacy' is a hard problem, including just for UI "porcelain". In part because people are used to what there is. (Which is a reason it's hard to get people to switch to something that isn't git either -- enough people have figured out how to do what they need with git as it is, and most people don't like having to learn new tooling).

Everyone agrees that moving from svn to git was a net positive, nobody likes svn better.

Git is pretty good.

But it's UI can be weird. And I am pretty sure if we check back in another 10 years, if people are still using git, it will be with the same basic UI model, little "fixable" will have been fixed.

Doesn't mean it'll be a disaster, we're doing okay with git. But I don't think the "UI issues are fixable" argument carries much weight here.

(Other alternatives may have been better, it can sometimes be a mystery or subject to debate why one product "wins".)

Re: Oh shit, git (2016)

#143

Post by dangravell »

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…

My guess is that git is a supporting tool to the main task. As such, it's tempting to always search for the next solution for a git problem on StackOverflow, or wherever, rather than actually learning the concepts behind git.

If people _did_ learn those concepts, they wouldn't find it "impossible to grasp" and then it would be more appropriate to compare one's knowledge of git to their programming knowledge.

Re: Oh shit, git (2016)

#144

Post by jrochkind1 »

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!

Re: Oh shit, git (2016)

#145

Post by dotancohen »

teekert wrote: post #53
_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.

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 ugly and daunting when you start with it, but as you get to know it you start to appreciate it's beauty and elegance

This, exactly. Git was written by Linus Torvalds. You could literally replace the word "Git" in that sentence with any other software written by Linus Torvalds and it would remain just as valid. The guy writes software that has a learning curve, but does does its job elegantly. He's not writing software for the social-media-no-attention-span crowd.

Re: Oh shit, git (2016)

#146

Post by gwright »

q3k wrote: post #133
ghiculescu wrote: post #132

> git reset HEAD~ --hard Seems fairly magical compared to other stuff here. To me at least. Can anyone briefly explain what it does?

HEAD~ means 'the second to last commit in the current branch' (ie. the second to last when you `git log`). git reset means 'point the current branch to this commit instead of wherver it's pointing now' (branches in git are just pointers to commits) git reset --hard means 'also reset the state of the checkout and staging area to be in sync with the commit' Thus, the entire spell means 'reset the current branch to make…

[Edit: It seems that I was mistaken but I'm leaving this up to illustrate the confusion. In my experience "second to last" isn't common and "next to last" is much more common, which I think is why I was confused because I thought they were different, but apparently they are the same. I wonder if there is a regional usage pattern to these phrases. ]

This seems like mistake or a non-standard usage of the english phrase "second to last". Given a git log of:

    $ git log --oneline
    15e0437 - (HEAD -> master) this is the third commit
    f82d1fd - this is the second commit
    9180c17 - initial commit
I would call "f82d1fd" the "next to last commit" and it can be referred to as HEAD~ I would call "9180c17" the "second to last commit" and it can be referred to as HEAD~2

Re: Oh shit, git (2016)

#147

Post by jnbiche »

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

imho the natural default for any of these types of commands should be to reset the worktree, never the index. In my experience, people almost always want to review a file before they stage it, even if it's coming from HEAD.

So `git restore file` should reset the worktree, if you allow an unflagged version of that command.

Re: Oh shit, git (2016)

#148

Post by the_gipsy »

saagarjha wrote: post #2

> I committed and immediately realized I need to make one small change! I think it might be nice to add a disclaimer saying that this is not advisable if you've already pushed the code. Suck it up and make a new commit–don't rewrite public Git history.

> Suck it up and make a new commit–don't rewrite public Git history

You're most likely making things worse. Not only will you have the mess-up commit(s), but also the un-mess-up revert-commit. It gets super hairy when reverting merges (I assume you're not rebasing + fast-forwarding if you lobby against rewriting).

There is no big deal in rebasing to a rewritten master branch. It's just like any other rebase.

IMHO, rebasing signals that someone wants to apply a patch, and knows exactly where. Merging/reverting/etc. signals someone wants to "upload his latest stuff", like to a dropbox.

Re: Oh shit, git (2016)

#150

Post by ethbro »

darkpuma wrote: post #43
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…

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.

Post reply on HN