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

61–70 of 280 posts

Re: Oh shit, git (2016)

#61

Post by tluyben2 »

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

Re: Oh shit, git (2016)

#62

Post by tluyben2 »

thatoneuser wrote: post #24
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…

OK hot shot. Tell everyone here how you've never fucked up commands and had to blow out a repo and start over and how were all idiots for having done that. It's a tool. Any tool can be confusing if the person isn't taught how to use it. Git requires teaching so there's a lot of room for misunderstanding.

No hot shot either but that literally never happened. It happened with cvs but not with git.

And confusing can be and imho in this case is, something else than difficult.

Re: Oh shit, git (2016)

#63

Post by mehrdadn »

_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 Introduction > widget/readme.txt
  $ git add widget
  $ git commit -m "Initial commit"
  $ echo Conclusion > widget/readme.txt
  $ git checkout widget
  $ cat widget/readme.txt  # No "Conclusion"??

Re: Oh shit, git (2016)

#64

Post by mehrdadn »

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

> if you find git hard how or why are you writing code? That is surely a lot harder.

So many things wrong with your premises...

How do you know every git user is writing code? Is git only for code now?

And in the code case... were you born knowing how to use git? Or were you forced to learn it before you wrote a single line of code? Or were you forced not to learn it until you were a pro coder? Is it difficult to fathom something landing between these extremes?

Re: Oh shit, git (2016)

#65

Post by fulafel »

mehrdadn wrote: post #57
fulafel wrote: post #33

Earlier quoted context omitted.

But you can't safely rebase that branch! Having rebased it, you would have now broken it for others working on it. So this is a great example how the damage spreads and taints other branches around the history rewrite. (And even arriving at the "ok i could fix this with rebase" diagnosis will have been painful and frustrating and eaten time & energy, and you can't be sure you got away with it before actually doing it…

> But you can't safely rebase that branch! Huh? You don't rebase their branch. You rebase your own changes on top of their branch, which they happened to recently rewrite. Just like you might rebase your changes on top of master after master has undergone changes. I think the parent's point was that it doesn't matter if the branch was rewritten or just extended; either way you rebase the same commits on it the same w…

The "own" branch is also public here and maybe collaboratively worked on

Re: Oh shit, git (2016)

#66

Post by jolmg »

anujsharmax wrote: post #52
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…

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.

Re: Oh shit, git (2016)

#67

Post by mehrdadn »

fulafel wrote: post #65
mehrdadn wrote: post #57

Earlier quoted context omitted.

> But you can't safely rebase that branch! Huh? You don't rebase their branch. You rebase your own changes on top of their branch, which they happened to recently rewrite. Just like you might rebase your changes on top of master after master has undergone changes. I think the parent's point was that it doesn't matter if the branch was rewritten or just extended; either way you rebase the same commits on it the same w…

The "own" branch is also public here and maybe collaboratively worked on

So then anyone building on it would rebase the same way you just did? Which was the same way they would have done so if you had just pushed a new commit?

Re: Oh shit, git (2016)

#68

Post by masklinn »

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.

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.

Re: Oh shit, git (2016)

#69

Post by darkpuma »

jchw wrote: post #45
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…

Hg actually does go beyond Git in many areas; I did outline a few but my favorites are the improved commit model (stages, natural branching, rewrite tracking,) the commands Git doesn’t have (absorb, evolve,) and the extensibility (see Facebook extensions.) Sure, the model is similar and Fossil is different. But that is kind of an important note. If Fossil can’t be compared on the same level, maybe that’s a sign it so…

> If Fossil can’t be compared on the same level, maybe that’s a sign it solves fundamentally different problems.

Or Fossil provides a superset of the others. Like comparing a corkscrew, which only opens bottles of wine, to a swiss army knife that has a corkscrew. They both solve the same problem, but one of them also solves other problems and is generally a more useful tool to keep around in your pocket.

The world didn't lose much with Hg losing to git. But with Fossil losing, we lost a great deal. As a consequence we have a world where people feel locked into the proprietary bug trackers their git host provides. Had Hg prevailed, that situation would be no different. The only way the world would be different if Hg had prevailed would be fewer posts on HN whining about git's interface being obtuse. Not really a substantially different reality, is it?

Re: Oh shit, git (2016)

#70

Post by mehrdadn »

kkarakk wrote: post #58
Chazprime wrote: post #55

Earlier quoted context omitted.

Nope. You can use Git for versioning all kinds of assets...3D models, fonts, textures, music. I know someone who stored his book on Github and took pull requests from editors.

Yes but those are hacks, no one should immediately reach for git as a tool to version EVERYTHING just because you can. If you treat git as a convenient hammer for your screw, don't be surprised when the screw breaks at an inopportune time

Are you imagining every use of git is either (1) a Computer Scientist writing Code, or (2) a hack? You can't imagine anything in the spectrum in between? LaTeX papers by academics in various fields, scientific coders (MATLAB etc.), people writing stuff in Markdown, students who are still learning even CS, etc. are all doing the wrong thing by using git?
Post reply on HN