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

111–120 of 280 posts

Re: Oh shit, git (2016)

#111

Post by mehrdadn »

rusk wrote: post #107
mehrdadn wrote: post #63

Earlier quoted context omitted.

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

What you did there is the equivalent to a `revert` in SVN ... I'm not sure what the issue is? Why would you checkout `widget` and not expect local changes to be overwritten? Like, that checkout reverts is one of the first things you learn with git ...

> What you did there is the equivalent to a `revert` in SVN ... I'm not sure what the issue is? Why would you checkout `widget` and not expect local changes to be overwritten? Like, that checkout reverts is one of the first things you learn with git ...

Why would you sudo rm -rf / and not expect to destroy your system? Why is --preserve-root the default when that's clearly not what the command means? Like, that -rf wipes everything recursively is one of the first things you learn with rm...

Also see https://news.ycombinator.com/item?id=19907882

(P.S. also note the question wasn't even about whether this is expected behavior, it was just about whether it's possible to lose information when using git.)

Re: Oh shit, git (2016)

#112

Post by falsedan »

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

It's common for people teaching others how to use git to start off the lesson with some sort of disclaimer about git being really hard. I think this is a huge mistake. I suppose it's meant to prevent the student from feeling discouraged if they happen to struggle, but the student struggling with git is not a foregone conclusion. Such statements can demoralize the student before they even dive into it though. When you…

I usually couch git intros with "git was designed for linux kernel developers to get their work done, specifically filesystem developers, specifically Linus, so a lot of things won't make sense unless you approach it from the mindset of the above. don't worry! that mindset is probably different to yours but you can learn a good approximation to it and then you'll be really good at reasoning about git"

Re: Oh shit, git (2016)

#113

Post by bicolao »

mleonard wrote: post #110
bicolao wrote: post #97

Earlier quoted context omitted.

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

Hi. Interesting to know thanks! Would you mind giving the current commands to achieve the three things you just listed? That way I learn the future restore command along with the current approach and you description. T

"git restore --staged" should be the same as "git reset -- file" (--mixed, --soft and --hard cannot be used with individual files).

"git restore --worktree" is the same as "git checkout -- file".

"git restore --source..." should be the same as "git reset --hard -- file" if --hard was made to work with individual files.

Though "git restore" should make it clear (or clearer) to the user what they want to restore without resorting to more mysterious options like --hard/--soft. So if that's not obvious from my examples, I think I've failed :)

Re: Oh shit, git (2016)

#114

Post by aasasd »

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…

I feel like Git's concepts got tied into a mess in its cli tools. Like the devs maybe tried to imagine what would be the proper interface for a person not deeply familiar with the innards, but failed, and e.g. `git-show` is the result.

So I get this vague feeling that someone could build a better human-oriented suite of CLI tools on top of Git's internals―with the internals better mapped to people's more casual understanding of the concepts and their aims.

But that someone isn't me, yet.

Re: Oh shit, git (2016)

#116

Post by otikik »

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

Re: Oh shit, git (2016)

#117

Post by sc11 »

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…

> I kind of wish Gitlab would implement Mercurial support. I bet it would help Mercurial gain more adoption within teams working on closed source projects. I know Bitbucket does, but to be honest that doesn’t really appeal to me much.

There is some work being done on it, including a prototype: https://gitlab.com/gitlab-org/gitlab-ce/issues/31600#note_15...

Re: Oh shit, git (2016)

#119

Post by rusk »

mehrdadn wrote: post #111
rusk wrote: post #107

Earlier quoted context omitted.

What you did there is the equivalent to a `revert` in SVN ... I'm not sure what the issue is? Why would you checkout `widget` and not expect local changes to be overwritten? Like, that checkout reverts is one of the first things you learn with git ...

> What you did there is the equivalent to a `revert` in SVN ... I'm not sure what the issue is? Why would you checkout `widget` and not expect local changes to be overwritten? Like, that checkout reverts is one of the first things you learn with git ... Why would you sudo rm -rf / and not expect to destroy your system? Why is --preserve-root the default when that's clearly not what the command means? Like, that -rf w…

> Why would you sudo rm -rf /

Come now, that's being a bit hysterical/hyperbolic. There's plenty of other things you could do in the course of your command-line activities that are at least as destructive.

I know your example is meant to be trivial but there are plenty of ways when you're mucking about with pipes to ruin your day.

Like I say, "it is known" that git checkout is destructive, and while I can sympathise that perhaps the "-rf" is implicit I honestly can't see how you'd end up doing something like that in day-to-day activities, and if you did ... well if you'd spent any significant amount of time on it it probably should have been checked in anyway.

EDIT if you want to see some "good" examples of how you can inadvertently trash everything take a look at https://svnvsgit.com/ (warning, not as impartial as the title might suggest).

Re: Oh shit, git (2016)

#120

Post by dagw »

mehrdadn wrote: post #91
dagw wrote: post #84

Earlier quoted context omitted.

First of all I read it as using git in those ways are hacks (in the computer sense), not that the people using git in those ways are hacks (in the bad at your job sense) Secondly I think his point is (and I kind of agree) that while you certainly can use git to version you documents, 3D-models, and InDesign layouts, it's not necessarily the best tool for the job. Sure if you're already well versed in git go ahead and…

> First of all I read it as using git in those ways are hacks (in the computer sense), not that the people using git in those ways are hacks (in the bad at your job sense) Yes that's why I said "every use of git [...] (2) is a hack". > Secondly I think his point is (and I kind of agree) that while you certainly can use git to version you documents, 3D-models, and InDesign layouts, it's not necessarily the best tool f…

What do you see as the best tool for the job?

Depends on the job. If you're making a game in Unreal, perhaps take a look at Perforce and Perforce integration that Unreal offers. Doing post work on a movie, consider something like Alien Brain. Doing some collaborative writing with a bunch of non-technical co-authors, then the tools that come with Google docs might be the best fit for you.

Post reply on HN