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

71–80 of 280 posts

Re: Oh shit, git (2016)

#71

Post by mehrdadn »

kyberias wrote: post #13
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…

I think you are right about the DAG. Once I understood what the high-level data structure of git is, many branch related commands immediately made sense and it was suddenly very easy to use. Many of my colleagues haven't taken the time to learn that and continuously struggle with basic commands.

Honestly the DAG isn't the whole story. The distributed nature also adds a twist that makes things entirely difficult, and the obtuseness of the commands is yet another layer of difficulty. People have every right to expect git commit to commit their changes to the remote repo. And it very well could, but it just doesn't happen to. Similarly you can't tell me with a straight face that notion of having to 'git add' a file you just deleted in order to be able to commit that change is somehow intuitive. I could go on and on but the point is knowing the DAG is hardly the end of the story.

Re: Oh shit, git (2016)

#72

Post by deathanatos »

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

The common case is that I'm working on a feature branch, and realistically, nobody else is on that branch. If it's so big that someone else has a need to start using the code, I start looking for ways to subdivide the work that don't conflict/depend (i.e., the new work can be a separate branch based off master).

There are definitely exceptions, and a co-worker that I work closely with have one just last week. My stuff is based off his. If he changes anything (adds new commits, or rewrites current ones), my "pull" is just to rebase onto whatever his new tip is. If I have a fix to his commit, I just commit that in my branch; at that point it isn't work the trouble. When we're done, we either merge his (and I rebase onto master) or we just feel lazy and merge both by merging my branch.

Having a branch on a branch on a branch has yet to happen, and honestly, at that point, I think we'd just wait for the upstream branch to land.

Honestly, for 99% of cases, you know what the effects of rebasing/rewriting will be. It's feature branch that only you're touching? Go wild! In the middle of a code-review? Maybe write the commits in the --auto-squash format, and wait until approval before actually running rebase. Someone else is based off it? Maybe give them a heads up. For the few spots where it's ambiguous, a little bit of "hey, I'd like to X for reasons Y, ok?" is all it takes.

Re: Oh shit, git (2016)

#73

Post by louiskottmann »

kinkrtyavimoodh wrote: post #31
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.

I think many believe that "this should be easy, just add commits and get versioning, voilà!" and thus never invest the time (what, 2 days max?) to actually dig in, try a few common scenarios on a dummy repo, before actually using it on a live project.

The truth is, it's not so easy a task to get versioning right and git does, people are not humble enough.

Re: Oh shit, git (2016)

#74

Post by tropdrop »

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…

Most of OP's post isn't just the basic Git commands - it's super-user features that might help a novice who can do the basic add/commit/push/pull chain but doesn't even know you can revert in Git history, or make new branches.

Nothing shameful in someone sharing that knowledge to help a newcomer become a super-user faster.

Re: Oh shit, git (2016)

#75

Post by fileeditview »

mehrdadn wrote: post #63
_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…

Wow just tried this.. is this considered a bug or a feature and where can you read about this if it is intended behavior?

Re: Oh shit, git (2016)

#76

Post by tropdrop »

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

Git isn't hard but it's usually taught like absolute shit. From the get go you're told to use 4 commands, 2 of which are usually not explained and when they are it's often hand wavey. From there on its usually people pontificating about high level philosophy while failing to give concrete working examples. At least that was my experience. I'm decent at got now for the work I do so I'm cool with it. It really is an aw…

It's just one of those tools that is very foreign to new users, but once you know how to use it, you can't remember not knowing how to use it because it's so easy... this is like a lot of programming, actually.

Re: Oh shit, git (2016)

#77

Post by mehrdadn »

fileeditview wrote: post #75
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…

Wow just tried this.. is this considered a bug or a feature and where can you read about this if it is intended behavior?

Probably a feature given how many gazillion meanings they've given to checkout intentionally, but I have no clue. Hopefully it got the point across though ;) and I'm pretty sure it's not the only way to lose info in git...

Re: Oh shit, git (2016)

#78

Post by collyw »

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 know some people know git in depth but for me its a tool that shouldn't be main the focus of my work. It should work and get out of the way (which it does for basic workflows). Its when something unusual happens that it is a pain in the arse to use and requires far too much understanding in my opinion.

Re: Oh shit, git (2016)

#79

Post by collyw »

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

I want to focus on code and not be wrestling with a version control system.

Re: Oh shit, git (2016)

#80

Post by batisteo »

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 components. And it already have its own „Github” called the Nest (because pijul is a bird). Pretty promising imho.

Post reply on HN