Hacker News Reader

> It's honestly crazy how much time we as a community of software developers spend thinking about Git.

It's funny, I can't remember the last time I had to give serious thought about how to use git.

Sure, there's a learning curve. When I was just starting out, I didn't get it all right away. But it's been years since I've thought much about branching strategies and stuff. And I don't get myself into "terrible messes" that take hard thought to get out of.

Not saying you're 100% wrong. But it doesn't line up with my experience.

What rings truer to me is that it's crazy how often building a tool or process, etc, eventually turns into people being able to make careers of just that thing because of all the spins and metaprocesses people will throw on top of or into it.

Git springs to mind for one, but (capital A) Agile definitely wins the championship.

Most teams or companies I've worked in have a git guru but it's far from all they do. It's the occasional stop by at that person's every so often for help with something that is outside the absolute basics.

Sometimes it’s just that by taking enough out, it becomes unclear and complicated. I “taught” eXtreme Programming to two of my own teams by showing them the book. Worked like a charm. I also participated in several “Agile” installs that failed despite training, meetings, demonstrations, etc. All because removing the “customer is in charge and developer is allowed to get the job done as they see fit” component made it complicated.

I am with you on this. Its been years since I had an issue with git, and branching strategies are not that hard. In smaller teams most solution that show up are also usable. I would argue git is actually a fantastic tool that gives immense value year after year for no cost compared to any other alternative. There is a learning curve though.

If you've never had a git commit FAIL (eg https://github.com/okonet/lint-staged/issues/565) you aren't very experienced with git. By your description, you've probably just used it casually a lot. You don't do anything complicated and conclude that git isn't complicated. Given the history of working with:

* Submodules

* Binaries

* Large Repositories/branches

* A disparate set of development platforms/clients

* Git auth/credentials

The largest git repo I touch has half a dozen submodules (some with their own, you have to do a recursive clone), about two thousand branches (historically, we prune them) and about two hundred thousand commits, and has committers on Windows, Mac, and Linux.

It doesn't have binaries in it, 'cause git-lfs. But I don't remember the last time I had a problem with it other than PEBKAC rebases and the like.

> * Submodules

> * Binaries

> * Large Repositories/branches

> * A disparate set of development platforms/clients

> * Git auth/credentials

I have experience with all of these things and have not had a commit fail.

lol, gatekeep much?

He asked why people spend so much time trying to work with git abstractions then claimed "works for me". It's not gatekeeping, when replying to strawmen. Try to keep track.

I don't think you are applying the principle of charity when reading his words.

>If you've never had a git commit FAIL (eg https://github.com/okonet/lint-staged/issues/565) you aren't very experienced with git.

I follow Linux kernel posts on vger.kernel.org and I've yet to see Linus complain about a git commit failing. I guess he isn't very experienced either?

Why would he "complain"? or say anything on that mailing list? More than that, it's still git version 1 right? Sigh.

You get to avoid the Valley of Despond when you, y'know, write the tool.

You could be very correct! I think Linus might not be an experienced "git for Windows" user

In that example, the user has configured git to ask their linter if it's ok to commit, and the linter is telling git "no" because it's failing.

The git portion of that is pretty straightforward, but whatever the linter is doing looks rather complex.

> If you've never had a git commit FAIL...you aren't very experienced with git. By your description, you've probably just used it casually a lot. You don't do anything complicated and conclude that git isn't complicated.

You make unwarranted assumptions about another person's experience base simply because it supports your position to do so.

I'm one of the git "experts" that occasionally helps unwedge people who are "wedged" with git.

Every time, they are mentally unwilling to learn git.

And before anyone mistakes that for complexity on git's side… often, these folks have trouble with even basic questions, like, "is this the change you intended to make on this branch?" when shown a diff.

It’s alarming how true this is. Many seem almost proud of the fact that they have no idea how to use their tools. That’s definitely not git’s fault.

I knew a team of devs whose workflow with git was to have a clone of the repo per branch they worked on.

Needless to say, this caused a bunch of issues that made them think git was bad. When I asked "why don't you just checkout the branch you want to work on?" The answer I got was "I don't like working that way... Now fix my horrible mess of esoteric git features that I misapplied"

> these folks have trouble with even basic questions, like, "is this the change you intended to make on this branch?" when shown a diff.

I've seen people like this too, when reviewing PRs, I often see unwanted code being committed, and I just don't understand why this keeps happening. One of my defaults when committing code is to run "git status", then run "git diff" on each file I'm committing. I thought this was a pretty well used flow, but apparently it's not.

Or better yet: `git add -p`

If you only ever use `git add -N .` and `git add -p` you'll never have unexpected changes in your commit.

Or better yet: `git add -e`.

I tell people to run git log -p --reverse origin/master.. and git diff origin/master.. to see what changes their commits are introducing and the overall change they're making before they actually push the branch up to the remote. It's essentially proofreading what you're going to submit before actually submitting it.

> And before anyone mistakes that for complexity on git's side… often, these folks have trouble with even basic questions, like, "is this the change you intended to make on this branch?" when shown a diff.

And yet I don't run into such behavior from people using SVN or mercurial.

Every SVN-using project I've touched has had countless examples of files accidentally being committed.

While I spend a bit of time fixing other people's messes, I have to agree.

I find the biggest issues are people who don't really understand Git enough doing silly things, or just being careless. Like somebody cherry-picking something to Master and then cherry-picking it to a branch we're working on, but on top of some stuff that has changed in that branch, requiring them to fix a merge conflict. But then when it comes to rebasing the branch on Master to merge it, you then have two more conflicts to deal with that you didn't need to have, if it had just gone once to the right place! It's not hard to fix, but annoying, and you risk introducing errors to the code if you accidentally miss a line or something.

So the biggest issues are probably 1) people not following our workflow, creating extra work to fix, 2) people not understanding Git enough; or possibly for some people, 3) you team/company's git workflow isn't very good.

In most teams for 3 (which is probably one of the more common ones), you really only need one or two people who really understand Git well to set up the workflow and enforce it.

Exactly, that something as trivial and obvious as version control costs so much mental overhead is completely bizarre.

Sure, SVN doesn't have as many features as git, and merging sucks, but it offers the most important features of version control (recording "who has done what, when", and undoing changes). Teaching SVN usage to a non-techie takes literally a few minutes (especially with an intuitive UI like TortoiseSVN), and it's very hard to break something.

And that's why everyone still uses SVN and git is this obscure minor player that's relatively unheard of.

That's why everyone should still use SVN (or even something distributed but friendlier, like hg or bzr) and git should be a minor-but-important player that's used where needed (like for managing the Linux kernel, which is what it's actually for).

But of course we've cargo-culted it everywhere, and anyone who objects runs up against the pervasive attitude that there are no bad user interfaces or difficult-to-use software, only stupid people.

>That's why everyone should still use SVN

Ah yes, good old normative claims.

The market wants what the market wants.

Whether it's specifically SVN doesn't matter really, the point is that no other version control system in history required so much mental effort to be "learned" like git. And the worst thing is that new people who don't know anything else than git think that this is normal.

What's happening under the hood is mostly fine (mostly, because git completely breaks down with large binary files, and solutions like git lfs don't help much with this problem).

What's really bad is the git "frontend", that there's no obvious standard workflow, instead there's a thousand ways to do the same thing. That's great if you have a lot of time for tinkering and meddling with the tools layer, but not when you simply need to get shit done. The version control system should essentially 'disappear' and never require attention.

I started on SVN. Had a stint using TFS. Eventually wound up in git. I vastly prefer git.

We had simpler, easier to operate version control tools. Git traded off some of that simplicity for other benefits the community at large seems to value enough to have migrated away from the simpler tools.

I'm skeptical the "git is too complicated for newbies" cry is truly a turning point in tech cycle where we see the folly of our ways and begin to decry the current flavor of the month at the new anti-pattern after enough real-world experience has been accumulated to show us the error of our ways.

I think it's just "I don't like the way this makes me feel".

Gitkraken is easy as pie to use and does everything you are mentioning.. not sure why people are so obsessed with command line stuff for version control.

Also anything like visual studio / vscode you have 99% of what you normally do right in the UI.

I think it's anal people who like to make things as complicated as possible who try to make git as complicated as possible for others.

We teach students SVN as a part of software engineering at the Uni where I work.

70% of students screw up their repository every year.

My experience is that SVN is just as hard as git for the purposes of managing versions and branches of your work.

I have had the same thought. It is laborious to use and people struggle with it.

99% of the behavior it implements people do not use.

Git is not the correct level of abstraction.

Here is an exhaustive (~99.5%) list of the git commands I use:

  git init
  git clone
  git clone --recursive
  git remote add
  git checkout
  git branch
  git merge --no-ff
  git add
  git add -p
  git rm
  git reset
  git commit [-a] [-m]
  git commit -p
  git commit --amend
  git submodule add
  git push
  git push -u
  git pull
  git log
  git show
  git status
  git update-index --assume-unchanged (aliased to ignore)
  git update-index --no-assume-unchanged (aliased to unignore)

The 1 in 200 is probably a git rebase -i.

If we're doing something other than git I'll be happy with those. Specifically add/commit -p are important to me.

"git stash" is something I used to use all the time, roughly daily.

"git blame" is also very useful.

"git bisect" is remarkably useful once a month or so. It does a binary search to find the commit that broke whatever thing you've recently discovered is broken.

Bisect might be one of git’s killer features: you rarely reach for it, but when you do it saves your ass and saves the day.

Recently my coworker asked for help tracking a regression after spending hours finding the culprit, I bisected it in a couple minutes and his mind exploded :-)

I’d encourage anyone using Git take a closer look into “git rebase -i” (interactive rebasing) combined with “git add -i” (interactive staging).

While working, I’m freely taking advantage of Git’s capabilities on a personal level, producing many sometimes messy WIP (work in progress) commits, trying things on short lived branches, reverting changes, and so forth, but afterwards I am able to copy edit the results to produce a sequence of finalized commits that form a coherent narrative that reads like how I would describe my work to a colleague or manager.

To me, interactive rebasing has been the difference between “my team uses Git” and “I first and foremost use Git for myself, and then also use it to share the results with my team”.

I nearly always "git rebase -i" before opening a PR, and even after. Squash, re-order, reword FTW. Recently I started using "edit" to split previously squashed PRs back out.

I like presenting and merging tidy changes.

me]$ cat .bash_history | grep git | awk '{print $1,$2}' | sort | uniq -c | sort -n

      1 git clone
      2 git cherry-pick
     10 git reset
     17 git merge
     23 git fetch
     34 git checkout
     37 git rebase
     66 git diff
     75 git pull
     79 git log
     87 git branch
    126 git commit
    135 git add
    141 git push
    201 git status
    205 git grep

    122 git bug
    124 git branch
    169 git show
    247 git reset
    274 git rebase
    308 git fetch
    310 git fixup
    576 git commit
    633 git push
    692 git pull
    889 git stash
    949 git diff
   1122 git add
   1681 git checkout

Where `fixup` is https://github.com/hashbang/dotfiles/blob/master/git/.local/...

I always recommend to people to not use 'git pull' as it's probably not what you really want.

What do I want? It sure seems to do exactly what I need in the case where I'm on my local `master` and it's exactly the state of `origin/master` but a day or two behind.

What is it you're doing on your local master? It's only going to lead to a mess if you're developing on master locally and trying to do merges from upstream.

Absolutely no development. I use it as my starting point for feature branches, as well as subsequent rebases and merges on them. And I use it to build and run the current master.

I run git rebase -i a lot more often because I like to reword a bunch of commits to make the commit messages clearer just before pushing.

And git reflog is indispensable for fixing things.

And I'm surprised you didn't mention git diff. I do that all the time to compare things, like having a single diff of all commits between the origin diff base and current HEAD. Also useful for summarizing changes of entire feature branches.

Git is like C++. People learn and use a different subset of it and everyone claims their own chosen subset is powerful enough and entirely sufficient for everyone.

Darn I actually missed git diff. I haven't been using a bash history so I don't have something check against. I'm confident now it's complete tho.

Rebase -i is a lot to fun, I ought to practice it more. Haven't had to use reflog yet, but I'll be expecting it now thanks~

I don't use git; years ago I chose mercurial and have stuck with it. And I'm by no means a power user. But I've always wondered why git "won".

git before github existed was a pain to use. I honestly just continued to use SVN because the tool support (like automatic renaming in IntelliJ when refactoring a class) just worked, and there was concern about exactly how to back up our source code.

After github, things became much easier and it is likely the main reason people use git over mercurial.

Of course, now I work at a place that uses Mercurial, because Git can't handle the size of our repo (an order of magnitude, at least, bigger than the Linux kernel)...

git even before github was a game changer for distributed development, kernel being the most prominent example. It did not require random people to have connectivity or authorization on some central SVN server, and yet they could clone and sync their trees and create branches to their heart's content.

But mercurial was also in play then and seemed better (which is why I chose it) or at least on par. Somehow git got more traction and is now the default.

As with programming languages or anything else, this would come with lots of trade-offs.

Whether it is programs like Photoshop and Excel or programming languages like C and JS, general purpose tools have a lot of appeal: learn the once, use it for anything.

Of course there is the opposite as well: niche tools that solve a specific problem in an opinionated way, like photo filter apps, Elm, R, etc...They have a lot of appeal too because they are better suited to the task at hand, but have limited use outside their specific domain.

But the most popular and widespread tools are always from the former group. R is great, but there are always going to be more python repos on github than R repos. If git was opinionated, it would serve a smaller niche better, but other niches worse, so it wouldn't be the industry standard it is today.

For better or worse, I've observed that powerful with footguns is always more popular than more limited options .

Eh? Branches and tags are just symbolic names for commits, and commits define the entire content of the filesystem for a codebase at that commit.

That's almost all you need to know. Get that down path and you're on your way to being a Git power user.

If you can't handle that, then maybe you can't handle programming either.

The last thing we need is more opinionated version control tooling. We've tried it (e.g., Mercurial), and it has failed in the market. But if you want opinionated version control tooling, well, there it is for you to use.

Instead of opinionated tooling you can just have an opinionated lead developer who tells his team how to use git. I'm the git expert at my work and my team spend no time thinking about git any more. New starters understand how we use git on the first day and after that we all understand what's going on.

This.

Git is a glorious tool, but such tremendous power implies a lot of complexity and a lot of different ways that you can work with it. You can have 10 engineers and find they have 10 different opinions and everything ends in ego fightings. The best way is to have an owner of this, make the team understand the governance issues being resolved with the flow and disagree and commit (pun intended ;)

People need to learn Git. Git has a "click" moment. Git "clicked" for me a few weeks after I began using GitUp, an FOSS Mac app. It visualizes Git, and doing advanced Git is easy from within there, and only committing some lines of code is easy from within it. Visualizing Git is really helpful.

A branch is a name that points to a git commit. Every git commit has a parent, so a branch also has all its parents. You have a current commit, known as HEAD, and you have a current branch.

Merge is when you make a commit that "fuses" two commits, leaving both in the repository. It is ugly.

Rebasing is when you reapply the diverging commits of a branch onto the commits of another branch. You give it a new base."

This is important: Branches are names for commits. I have two active branches currently, "floating-plugins" and "master." "floating-plugins" is where I'm working on a plugin system and inter-plugin communication. I made the logging system log a stack trace for warnings. When I did and tested this change, I quickly select the lines of code that bring about this change through a GUI, type in a short message, and commit. Suddenly, I need to implement a feature on "master." As I'm implementing it, I realize I also need the log-stack-trace-on-warn feature in master. So I rebase with floating-plugins, and now, I have that feature on master.

In another scenario, I might have had to reorder the commits on floating-plugins so I could safely rebase to just the commits I wanted on master. In yet a different scenario, a cherry-pick might have been appropriate. The unifying theme of all this is that you need to be able to visualize Git.

Git won't fix people who do not test in a disciplined way. That's a social problem.

Git let's me do a hotfix on a beta testing server while having other code on my current laptop, and then merge the changes together with a rebase.

"So I rebase with floating-plugins, and now, I have that feature on master."

Didn't you just break the golden rule of Git which is to never rebase onto a public branch?

Is that really a rule? We do that all the time.

The Golden Rule of Git [1]

The fact that a) there even needs to be a golden rule, b) it's not obvious c) not everyone knows about it ... and I'm sure for many other reasons is a very strong reason to be spooked.

Git is like uranium, powerful, but so many don't even know what they are getting into.

Or maybe it's like C++ - really dangerous, but after a while, you learn to avoid most of the pitfalls and then it starts to feel 'ok' even though such pitfalls shouldn't exist in the first place ...

[1] https://www.atlassian.com/git/tutorials/merging-vs-rebasing#...]

Rebasing onto a public branch and rebasing while on a public branch mean completely different things. The first happens all the time, the second creates problems for people doing the first.

Pardon my ignorance, but if you rebase while on master, are you not changing the master branch history for everyone? Isn't the point of the golden rule to not be re-writing the history of public branches?

That is exactly what I was referring to in my comment. We are saying the same thing.

Oh, ok yes, I see.

Again it troubles me that even the language of Git is sometimes ambiguous.

I feel that there should not be a 'golden rule' of something that should never be done - it's a flaw in the product. It simply should not be possible, or at least not with someone without super-admin rights.

I feel Git is very much an administrative level tool, and that there should be something else for devs; something that is fairly obvious, consistent, encourages/forces the org. the policy and makes it so that devs don't have to think to much and really hard to screw up. Admins can give special privileges to the 'true experts' on an as-needed basis.

“Rebase” is a bad name for what should be called “edit history”. Never edit the existing history of master. Always do edit the history of other branches to merge them into master.

I think git is pretty good. However there are a lot of random/bad blog posts giving supposedly expert advice about how to use it.

Do you remember the hellish experience that was SVN, or CVS?

I liked CVS with continuous integration. It was problematic if you strayed from the trunk for too long. But one of the big reasons for SVN was to handle directories and version them properly.

Lack of consolidated commit logs is reason enough to condemn CVS. Yes, scripts existed which attempted to simulate one but it's not the same.

Yes, that was a nice feature of Perforce.