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

31–40 of 280 posts

Re: Oh shit, git (2016)

#31

Post by kinkrtyavimoodh »

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…

Git being difficult has unfortunately become a meme, and like all memes, gets propagated irrespective of its truth value.

Like I get it, we all enjoy making fun of vi but imagine every thread about vi only filled with people harping about ":wq". It gets tiring real soon.

Re: Oh shit, git (2016)

#32

Post by scarejunba »

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.

I'm not the hot shot. The hot shots are all the kids from Berkeley and Stanford who figure this shit out as interns while supposedly fully-trained engineers with all the knowledge of data structures that should come with that think this shit is too hard.

I think I'd be completely unsurprised to see an intern successfully use `rerere` on a longer project of theirs.

Re: Oh shit, git (2016)

#33

Post by fulafel »

serpi wrote: post #26
fulafel wrote: post #22

Earlier quoted context omitted.

This then discourages ad hoc teamwork because you can't touch feature branches other than the ones you own. And because the results of getting it wrong are hairy, people will tend to stay away just in case. It's a chilling effect. Or, someone might have created another branch off your feature branch, because they depend on your work. Now you've creaed a time bomb for them when they try to merge their work after you'v…

you just rebase on top of their changes. No biggie here. It does not matter one bit if their branch rewrites itself underneath.

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 and waiting if your teammates will come kick you in the nuts. or worse, silently spend a day untangling their work.).

It's just fundamentally unsound.

Re: Oh shit, git (2016)

#34

Post by _pmf_ »

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.

Re: Oh shit, git (2016)

#35

Post by jchw »

_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 tracks its own history through rewrites. You get cool commands like absorb and evolve. It’s easier to extend than Git.

The only downside to modern Mercurial I can think of is it’s still slower than Git, by at least a bit. But it can scale incredibly far with its extensibility. For example, what Facebook did:

https://code.fb.com/core-data/scaling-mercurial-at-facebook/

So why does it never seem to get consideration? I guess it’s because of the insane proliferation of Github and Linux, which is definitely more a blessing than a curse. But it’s weird. Back in the CVS and SVN days, it didn’t seem like there was ever going to be a ‘network effect’ for source control like there is today.

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.

Re: Oh shit, git (2016)

#36

Post by gvd »

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

git reflog

Re: Oh shit, git (2016)

#37

Post by mehrdadn »

fulafel wrote: post #22
colatkinson wrote: post #4

Earlier quoted context omitted.

I think changing history is fine on feature branches that only you are working on, though. IMO the benefits of keeping commit history clean outweigh the cost of having to push with "--force".

This then discourages ad hoc teamwork because you can't touch feature branches other than the ones you own. And because the results of getting it wrong are hairy, people will tend to stay away just in case. It's a chilling effect. Or, someone might have created another branch off your feature branch, because they depend on your work. Now you've creaed a time bomb for them when they try to merge their work after you'v…

> This then discourages ad hoc teamwork because you can't touch feature branches other than the ones you own. And because the results of getting it wrong are hairy, people will tend to stay away just in case. It's a chilling effect.

Do you frequently go messing with a branch assigned to single developers on your team without any sort of prior heads-up? And then surprise them with new commits next time they push/pull? I guess if you do that then none of you can ever force-push, and it's great if that works for your team, but I feel like generally people try not to interject and instead give a heads-up before messing with others' branches, after which the original dev knows others are involved and can then avoid force-pushing (or sync up when needed).

Re: Oh shit, git (2016)

#38

Post by darkpuma »

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 tell your student that git is hard, you are doing them a disservice.

Re: Oh shit, git (2016)

#39

Post by lixtra »

broodbucket wrote: post #19
lixtra wrote: post #6

Earlier quoted context omitted.

I find it okay to rewrite public history in short lived feature branches. It’s typically your branch after all. So it would change your advice to: Don’t rewrite public Git history unless you can assume it’s read only. Patches for Linux get rewritten all the time till they are finally merged.

That's not public git history though, those are just patches on mailing lists. Even before it goes into maintainer's lists, in my experience it's extremely rare that a maintainer will force push to their own public -next branch.

EDIT: parent is right.

I see about 600 pull requests on github[1]. My understanding was that Linus moved away from mailing lists some time ago. But then I'm not involved in kernel hacking.

[1] https://github.com/torvalds/linux/pulls

Re: Oh shit, git (2016)

#40

Post by rich-tea »

yaseer wrote: post #9
wishinghand wrote: post #7

Earlier quoted context omitted.

What's a DAG?

https://medium.com/girl-writes-code/git-is-a-directed-acycli...

Unfortunately this article, like almost all others, is still wrong because it looks like commits get mutated when you rebase and the old commits disappear.

It is very important to understand that commits (in fact, all blobs) are immutable in git. You can only make new things. You can't modify old things. Git doesn't delete anything for a while either.

Post reply on HN