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

121–130 of 280 posts

Re: Oh shit, git (2016)

#121

Post by mehrdadn »

dagw wrote: post #120
mehrdadn wrote: post #91

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

How about the examples I gave here: https://news.ycombinator.com/item?id=19907595

And if you're going to claim they should be using online-only tools, please explain why it's wrong for them to instead choose the tools that work locally...

Re: Oh shit, git (2016)

#122

Post by otikik »

rich-tea wrote: post #5

Git is not hard. It's very simple. But people learn it the wrong way. You have to learn it from the DAG up. If you cannot grasp how the DAG works you'll forever be reading and writing articles like this one which do not help you to learn. This is a horrible article. You should not bookmark it or use it. If you're not a programmer, you shouldn't use git. If you are a programmer, do yourself a favour and spend a day go…

The gatekeeping is strong on this one.

Re: Oh shit, git (2016)

#123

Post by mehrdadn »

rusk wrote: post #119
mehrdadn wrote: post #111

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

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 computer should actually go ahead and shoot him in the face. Somehow you managed to take those 6 words out of context and focus on bashing the example while ignoring the actual real problem I was illustrating with it in your reasoning.

Re: Oh shit, git (2016)

#124

Post by rakoo »

IshKebab wrote: post #83
jayd16 wrote: post #49

Earlier quoted context omitted.

>and super smooth conflict resolution? Because the hardest part of conflicts is already the conflicting changes themselves and not the source control.

Sure but I've never found a GUI or editor that lets me resolve conflicts in the way I want. For example say I change one line of code in a big function. I rebase and that function has moved. Conflict! I want a tool that says "here's what you changed, and here's the current state of the source". None of them do that though - they all just show the conflicts that git writes to disk - the code after you changed it, and…

What you, and also I, want is a syntax-aware merge tool, i.e. one that can tell you the meaning of the change. If a function got moved to another place, or if 2 fields swapped places, I don't want it to have the same importance as na actual change in behavior. No importance, even.

Git's only sense of syntax is recognizing lines, and it's just not enough in too many cases.

Sadly in my (short) research everything I have found is either closed source or I can't afford to pay for it. It's even more saddening that git already has built-in bits for syntax related diffs.

Re: Oh shit, git (2016)

#125

Post by stevekemp »

batisteo wrote: post #80
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…

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

I had a sudden flashback to using darcs, which was also based upon patches instead of commits.

darcs was nice, up until you hit the exponential merge problem.

Re: Oh shit, git (2016)

#126

Post by aldanor »

jolmg wrote: post #66
anujsharmax wrote: post #52

Earlier quoted context omitted.

If you use Emacs, give magit ( https://magit.vc ) a try. It is so much better than Git CLI, which probably is too low level for daily usage.

I use the CLI for my daily work just fine, thank you. I sometimes turn to magit when I want to navigate a file's history through git-blame, though.

CLI is fine until you acquire a habit of committing things chunk-wise and line-wise. E.g., I have these 20 files modified, but I'll quickly skim through and add/commit the lines/chunks that are done, and then continue working on the rest. CLI promotes a different kind of workflow, like "ok, I'm done, add/commit it all, and then move on".

Re: Oh shit, git (2016)

#127

Post by rusk »

mehrdadn wrote: post #123
rusk wrote: post #119

Earlier quoted context omitted.

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

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 things you'd end up using if you didn't know what you're doing.

Re: Oh shit, git (2016)

#128

Post by aflag »

ddtaylor wrote: post #21

Many of these problems can be avoided by using a pull-request style workflow.

I don't see how prs would help solving any of those. It's common for me to use a few of these commands before I open the PR.

Re: Oh shit, git (2016)

#129

Post by masklinn »

rusk wrote: post #103
masklinn wrote: post #68

Earlier quoted context omitted.

Meh. Git has a shitty UI when you start with, and it still has a shitty UI years down the line. The underlying model is neat and interesting, but that you have to know it to find any usability or elegance is an indictment.

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.

Re: Oh shit, git (2016)

#130

Post by crispyambulance »

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 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 searches to eventually remember the commands that are appropriate for your workflow.

Post reply on HN