Hacker News Reader

Comment by lisper | Hacker News Reader

> Other than that, I recommend that people learn to use git properly.

Sorry to be harsh here, but that is completely useless advice. It's a tautology. Of course people should learn to use git "properly". What's the alternative, that they should learn to use it improperly? Everyone should learn to use everything properly. It's like telling someone dealing with a crisis that they should "take appropriate action", as if taking inappropriate action was something that someone would actually seriously consider absent this advice.

The problem is that no one knows what "properly" means when it comes to git. Git itself provides no clue, and everyone and their second cousin has an opinion. That makes the advice to use git "properly" utterly vacuous. Figuring out what "properly" means is the whole problem with git.

[UPDATE] See also my earlier comment here:

https://news.ycombinator.com/item?id=27580478

View on HN

I've always found it interesting that Git gets a pass for its horrible UX by so many devs. The programming community wants to provide too many options for _everything_. If there's a tool you don't like, there are probably 10 other versions that do similar enough things that you can just switch. Devs are harshly critical of tools. And yet, with Git, the response just seems to be "if you don't like it you must just not _get it_." Which, I guess is fair, but I don't particularly understand why everyone has to "get it"? Why can't we expect a tool that's used by so many be intuitive? Or at least, _more_ intuitive? It feels a bit like hazing at this point. The post recently about `git undo` was great, I think, because of the frequency with which users encounter surprising and unintended behavior.

It continues to be kind of frustrating to me. It feels like a tool that should be wrapped in something else and never even brought up to 99% of users. A half finished idea on productivity and team centric version control (to get ahead of comments: I know it's not designed to be that, but that's how it's very frequently used).

It's not like there aren't more than ten different tools that do approximately what git does, but a little differently. There are also dozens of UIs on top of git. So the response to git's UI is not uniformly "RTFM", many people tried to provide alternatives.

Well, that's why it's called git. Everybody has to get-it.

>And yet, with Git, the response just seems to be "if you don't like it you must just not _get it_." Which, I guess is fair, but I don't particularly understand why everyone has to "get it"? Why can't we expect a tool that's used by so many be intuitive?

There are lots of UIs for git - many people on this forum will advocate for using one. My personal experience is that a UI manages to over-simplify the git workflow. It never quite allows you to perform all of the useful tasks you want, unless your use of git is very basic.

In a more general sense, git can also be considered quite conceptually simple; "getting it" is not the real problem most users have. The confusion about what commands do comes from the fact that users learn the tool backwards. No job bothers to teach a junior developer about the DAG and what commits, branches, and refs really are. Instead, they are forced to start with git's large and crufty CLI - so it's no surprise that it's hard to pick up any intuition about what's going on.

And that's a problem with lots of technical teaching, not just git. Since the focus is on getting immediate observable results, and not on conceptual understanding, users tend to learn how to use tools instead of how they work. That creates a culture of "I don't know what this is doing, and I'm too scared to mess with it" - basically the anti-hacker mentality.

> And that's a problem with lots of technical teaching, not just git. Since the focus is on getting immediate observable results, and not on conceptual understanding, users tend to learn how to use tools instead of how they work. That creates a culture of "I don't know what this is doing, and I'm too scared to mess with it" - basically the anti-hacker mentality.

yeah I guess I don't really align with the "Developers must learn the internals of all of the technology they are required to touch", and I don't really agree with the sentiment that that decision disqualifies one from "hacker mentality".

>I don't really align with the "Developers must learn the internals of all of the technology they are required to touch"

The DAG, commits, refs, etc. are not the "internals" of git - they are the basic building blocks of its mental model. Without them, there is no way to understand what git is doing - so it's no surprise many people think git is unintuitive, because they aren't taught what those concepts are.

The thing I'm saying is counter to the hacker mentality is using a tool as a black box, without understanding what it does and what it is trying to do. You don't have to read the code and know all the technical details.

Lots of users treat git as a small set of known commands that they execute in sequence until the repo is in the state they want; and any deviation from that happy path is met with a repo wipe and re-clone. A hacker should be happy to play around with various man pages and commands to build an understanding of what each command really does - and then be able to fearlessly mix and match commands, because they know how they are affecting the repo at each step.

> The thing I'm saying is counter to the hacker mentality is using a tool as a black box, without understanding what it does and what it is trying to do. You don't have to read the code and know all the technical details.

And I'm saying that this statement is just hustle culture nonsense.

> A hacker should be happy to play around with various man pages and commands to build an understanding of what each command really does - and then be able to fearlessly mix and match commands, because they know how they are affecting the repo at each step.

No true scotsman would use git without reading books about it!

This is just nonsense. Gatekeeping holier than thou nonsense.

Love the attitude. I also print out my man pages.

I love that my comment was meaningful to you enough to make an account and comment.

I use SmartGit (there are many other visual tools), as I have no interest in untangling the utterly hostile Git command-line interface. Using the terminal to stage chunks of a file? No thanks.

I feel no embarrassment about it either. You may pride yourself in using Vim, while working on a multi-thousand-file project. You are a power user, good for you. Now go collect other time-wasting useless accolades, like Pokemons.

I really don't know what you are getting at. I find it really intuitive and it seems like one of the best pieces of software created.

Don't use it blindly. Learn it enough that you understand those mystical incantations and aren't summoning Cthulhu by accident, only on purpose

Don't cookbook it, understand what the thing you're typing means. Don't use a GUI to abstract it away, be familiar with the CLI and what it's doing. Don't default to rm-rf when you get stuck, check git reflog and see if you can unfuck yourself first. Ask someone who doesn't have your problems how they're using it - it's possible you're "holding it wrong" in some obvious way, but in a way that masks the true problem that's biting you.

Some of my coworkers regularly have problems with git - I don't, and some other coworkers also don't. We all use roughly the same workflow, it's the people familiar with "what does pull --rebase really do?" that don't get into trouble and/or can get themselves back out of trouble, and the ones who always type the same command regardless of the situation that have problems.

Learn your tools, inside and out.

In my eyes all you did with this comment is join the people your parent poster is arguing against; you kind of just reiterated the stance they don't like. Not sure how constructive such a comment is.

> it's the people familiar with "what does pull --rebase really do?" that don't get into trouble and/or can get themselves back out of trouble

Absolutely not my experience. No small amount of people who seem to be doing more with GIT than me regularly get into trouble. Has been the case in at least 7 companies so far. Check your selection bias.

> and the ones who always type the same command regardless of the situation that have problems.

People like you forget that we use tools to make our lives easier. Tools. Not a whole damned ecosystem of dyslexic scripts that can't make up their mind even on a common CLI switch convention...

> Learn your tools, inside and out.

I am not paid to know GIT inside out. I am paid to deliver and fix code and to not step on other people's feet. I am aware that the second part is what many deem to be an ideal case for knowing GIT inside out but not to me and not to almost all devs I ever worked with. I do indeed want to issue one command and be done with it.

GIT does a poor job of bringing remote changes into your branch, for example. As other commenters have pointed out, it can do much better, like detect concurrent identical changes -- which is something that happens often in big teams, people just swing by a module and fix a trivial bug and include it in a bigger PR. You can argue until the end of days that's not a good dev team practice but in the end these things still do happen and this supposedly amazing tool is supposed to handle it. Guess it isn't designed for that?

> It's possible you're "holding it wrong" in some obvious way

"Obvious", sure. As if I care what an index, staging area, reflog etc. are. I don't. But GIT's team has been stubborn. This article seem to show some desire to improve UX, which might go contrary to what you feel what GIT users should do. ;) So I'd say even their team is starting to recognize some problems and are working to address them.

GIT's problem is super classical in all dev tooling. The creator(s) directly exposed the underlying data structures and are putting the onus on the user to learn them inside and out. As opposed to actually making a good UX.

Stuff like, say, "git sync" (which should do "fetch" + try to merge/rebase main branch with yours) should have been no-brainer right from the start.

> I am not paid to know GIT inside out. I am paid to deliver and fix code and to not step on other people's feet.

Your argument is still the same as the other git detractors, and is still wrong.

It _is_ part of your job, it _is_ part of delivering and fixing code. It's the same as anything else you're using. It may be a larger surface area that you're exposed to, but it's no different from CI/CD, build systems or something like a package manager. You don't need to understand how pip or npm or maven works to deliver software effectively, but if you get into trouble you have no alternative to rm-rf.

> As if I care what an index, staging area, reflog etc. are. I don't.

If you don't want to learn it then stop complaining about how difficult it is to use. That's your problem, not git's.

All of those things are important to the power of git. If you don't want / refuse to learn about them then you're trying to build your software with a car stuck in first gear and complaining about how slow it is. STFU and RTFM.

None of this detracts from your final point, which is valid! Just because the UX is mediocre (at best) doesn't mean you can't learn it.

The issue here is GIT is way more complicated to learn, because it has 10.000 options that might do what you want to do or do something else entirely.

Imagine your deployment pipeline required you to manually craft TCP packages to send to your machines to deploy code...would you still say "it _is_ part of your job, it _is_ part of delivering and fixing code", or would you say "that is stupid"?

With GIT, you are spending more time on learning and battling the tooling required to deliver code, than actually writing and testing the code.

Imagine git required you to manually craft TCP packets... That's what you're comparing to.

You're doing it really really wrong if you spend more time learning git than writing your code. Even with its bad UX it's just not that hard.

What's with the weird capitalisation; is git suddenly an acronym or something?

Nope, just my way of making sure it's recognized in a sentence.

> Figuring out what "properly" means is the whole problem with git.

I think you've missed OPs point by focusing too much on a single word ('properly'). Yes, there's no clear-cut way on how to use git, no silver bullet, but the main problem with git is that most devs simply panic when they have to do anything that goes beyond the bog-standard commit/pull/push/merge. Rebase? Squash? Reset? Rebase interactively? I think OP was referring to this cluelessness with 'not using properly', rather than which approach to git is the best.

I work on a monorepo with 40-something other devs, and we've recently switched to enforced linear history because the history got to the point of being completely useless, it was an unreadable spiderweb. The problem was not that folks didn't see that what they were doing was not-so-good (introducing often more merge-commits with every PR than non-merges), it was that they had no clue how to avoid that.

It took us quite a bit of time to get everyone up to speed but pretty much everyone got around to it after a while. It's not rocket science after all.

See my earlier comment here:

https://news.ycombinator.com/item?id=27580478

Regarding your first point (and I think some of the commenters in that thread also address this already) is that as long you don't have uncommitted changes, you're safe. You're right that a lot of git-commands mess with uncommitted changes in hard-to-recoverable ways, but once changes are committed, there's almost no way to mess anything up, you can always go back to the previous state (git reflog <branch> telling you which commit that was).

Regarding the second point - if you have a rebase-based work-flow, you will encounter this problem less often (or not at all).

For your third point - what helped me a lot is to actively distinguish between commits and the working tree, and making myself aware that branches really are just "pointers" to commits (obviously, but somehow, actively thinking about it made the intent of git commands a lot easier to understand). Also, most git commands are just combinations of other commands. git reset is just moving the pointer (--soft without touching the working tree, --hard will do so), rebase is essentially a hard-reset with consecutive cherry-picks afterwards, and so on.

Also, an eye opener for me personally has been that e.g. an interactive rebase with squash towards a branch that is strictly ahead of you except for the commits you want to rebase is essentially just a "git reset --soft <target>", and then recommitting everything with a fancy commit-message. This and similar mental gymnastics with git-commands has helped me a lot; most of them really are quite sane (except for all those crazy options), "git checkout" is really the odd-one-out of the bunch (and "git pull" a combination of things that should never have been combined in the first place).

Yeah. That clarified everything.

Honestly, if you were less busy sulking about it you might have had some capacity left to be receptive, in stead... And then it might actually have helped clarify a lot.

Also: In a discussion where one party is being helpful and the other sullenly sarcastic, it's not the helpful one that comes off as an asshole.

LOL. :D

I really am not sure if you were being sarcastic or are really that unaware what a mish-mash of specialized jargon you just threw at the guy.

Don't think you the proponents actually understand the problem. It's not that programmers are unwilling to learn (something that many elitistic people love to pretend so they look smarter), it's something called tool fatigue. You just want your tools to do their job and move out of the way which GIT absolutely does not do.

I know that one day I'll get completely sick of GIT and will research and learn it to the bone. Sure, it's bound to happen. But the fact that GIT imposes its internal data model on you and doesn't attempt to solve more problems for you from the get go is what many of us are ticked off about.

> I really am not sure if you were being sarcastic

I was not :P But the commenter also said in the linked comment that they "understand how git works", so I took the liberty to make a few assumptions ;)

> But the fact that GIT imposes its internal data model on you

It does, to some degree, but once you get a grip of "everyday commands" that go beyond commit/merge (cherry-pick, rebase, reset, reflog), it's actually almost surprising how little you have to know about gits internals. It does help to have an idea about them, though.

My main complaint about git is that most commands have too many options that make it do too many different things. And that resolving conflicts via command line is absolutely atrocious (something I actively avoid and discourage).

> I know that one day I'll get completely sick of GIT and will research and learn it to the bone

I can only recommend it! It's really not that hard as many people suspect (as I've mentioned, I have a bit of a habit of teaching people git at work). If you had any exposure to something computer science in the past, the puzzle pieces probably start to come together after some hours.

And it's probably one of the longer-lasting constants in our industry, so in my opinion, it's really worth it to know how to make good use of it.

I've tried the "rebase into a feature branch" workflow, which I think you are alluding to. Unfortunately, it always results in scary conflicts. So I go back to merging the main branch into my feature branch workflow, which works every time. I then hit squash in gitlab for my merge request, and no one is the wiser.

Should I be doing something different? As I said, rebase in that situation is disastrous. Many folks recommend it vigorously but are not around when things inevitably go wrong.

I don't know, most people I've seen "scared" by merge/rebase conflicts have simply been scared by the UI provided to resolve them. It's just a matter of spending a bit of time familiarising yourself with what you're seeing and understanding what the tools are doing.

There's a bunch of resources on that and once you wrap your head around what git is doing it shouldn't be too hard to figure out how to navigate conflicts.

Merge conflicts in a rebase can propagate through every commit in your feature branch (suppose that you modify a boilerplate line in 10 commits, and you get a conflict on that line in the rebase, you now have to solve that conflict 10 times possibly with some interference with nearby conflicts)

In many cases also there are problems with git being line oriented rather than token oriented, IMHO I would have expected language aware diffs (for definition of "words" and maybe parenthesis) for common languaged to be common place by now (maybe even with a language server support)

In my team we are lucky as most conflict are a matter of simply choosing a side and overwriting the other.

>Merge conflicts in a rebase can propagate through every commit in your feature branch (suppose that you modify a boilerplate line in 10 commits, and you get a conflict on that line in the rebase, you now have to solve that conflict 10 times possibly with some interference with nearby conflicts)

Yes, this is true. But in a lot of cases this is a relatively trivial fix. That being said, I do think git could do better here. But I have not had it happen very often (and usually I know when it's about to happen so I know what to expect).

> In many cases also there are problems with git being line oriented rather than token oriented, IMHO I would have expected language aware diffs (for definition of "words" and maybe parenthesis) for common languages to be common place by now (maybe even with a language server support)

Language aware diffs would be a neat idea indeed, but I guess the issue may be that now git would need to have metadata to tell it which language server to use for which file.

I wonder if it would be possible to give git a plugin system for diffs, just have an option to offload to a diff program which could handle the metadata separately.

> [...] in a lot of cases this is a relatively trivial fix. > [...] I have not had it happen very often

Often it is simple but it is tricky and hard to practice. Part of the problem is not git fault, it is just that thinking in diffs is not easy.

> metadata to tell it which language server to use for which file

My understanding is that git already does this (via filename or custom helpers) for binary/text files, I believe that it is used only for newline conversion, but for most usecases filename-based rules in a gitignore derived syntax would be enough.

Currently for binary files git has heuristics described in gitattributes(5) and these only go as deep as text encoding autodetection and the ability to specify the text encoding of a file or mark a file as binary. It's not sophisticated enough to know what kind if file it's looking at outside of just that.

> Unfortunately, it always results in scary conflicts.

I think you're referring to what I call "conflict cascades"? E.g., you're 4 commits ahead of "master", and want to rebase on top of it - but you have a conflict with your first commit, and after you resolve it, this results in conflicts in the second one, etc.?

It's a very interesting question because it's one of the main pain points of rebase that simply does not exist with merge.

What I've found for myself is that it's very important to create "atomic commits", which do not rely on other commits to make sense or "be complete". For example, a very common thing that I see is "fix formatting", "fix tests" commits, because some build was complaining about something being broken. And it's often these kind of commits that create weird conflicts (especially the formatting ones) because just a lot of code is moved/refactored/added/removed etc.

But do these commits make sense on their own? For example, if you have a history as follows:

    <commit-1> Introduce new fancy feature
    <commit-2> Fix formatting
    <commit-3> Fix tests

Does it make sense to ever check out <commit-1>? No, right, because that commit is broken - wrong formatting, broken tests. What you want is always <commit-3>. So why not just adding those changes directly to commit-1 by using commit --amend when committing or by using fixup in an interactive rebase.

This was of course just an example, but in my experience, if people follow these kinds of trains of thoughts - what can be in a separate commit, what should be together, etc., there is an inherently smaller conflict-cascade-potential, which pays off a lot when rebasing. On top of that, it also makes history generally more readable and individual commits more meaningful and easier to cherry-pick.

Not really. I give up on the first conflict, because dozens of files are in conflict and they are often incomprehensible.

I've never understood - or used - rebase as a standard part of a workflow. And I've been using git for nine years.

What is wrong with a master branch whose history reads "Merged feature foo" after "Merged feature bar"? If you need more detail then check out the feature branch and git bisect to your heart's content.

I do wish that we could "archive" branches from the output of `git branch -a` but really it's not a big deal when branch names are prefixed by Jira ticket identifiers.

I had this opinion for the longest of times as well, but me and all the other devs I know who started using a rebase-based approach just don't want to go back.

I think it's also a bit a question of team size. If your project has just a handful of devs working on it, merge-commits really don't matter all that much. If there are a few dozen with a good amount of juniors on the repo (a bit over 40 devs in my case), the commit-history becomes an absolutely unreadable spiderweb, that's at least my experience.

At work, we want to move towards trunk-based development (merge to master goes straight to prod), but whenever master was broken, a look at the commit-history didn't really all tell you that much about the who, how and why without checking it out and digging into it. So we've recently started to enforce linear history, in which case it is immediately obvious without the shred of a doubt who's responsible. Analyzing the build became an absolute breeze, at the cost of having a bit of a harder time at "insertion"-point (which is perfectly fine, given the fact that after merge, it should eventually go straight to prod).

It took a while to get everyone on board, but it was really worth the efforts and can only recommend it (I most definitely will prefer a workplace that is open to such practices in the future). In general, most devs were also quite happy to be guided through the process, as it is clear that git is probably one of the longer-lasting constants in our industry.

Also, I can't repeat it enough; speaking from experience, most devs severely overestimate the complexity of cherry-pick/rebase/reset/reflog etc. Whenever I had sessions explaining it or helping someone out with a problem, they had their first "aha!"-moments after a few minutes, and after that with some do-it-yourself-experience most of them get there rather fast. Obviously, there are always a few outliers who need a little bit of extra-nudging and extra-help to stay in line, but those are usually the ones who often also need that sort of assistance in other areas so that's okay.

> I think it's also a bit a question of team size. If your project has just a handful of devs working on it, merge-commits really don't matter all that much. If there are a few dozen with a good amount of juniors on the repo (a bit over 40 devs in my case), the commit-history becomes an absolutely unreadable spiderweb, that's at least my experience.

git log --first-parent gives you a nice linear history of (generally) your top level merge commits. If you follow a PR workflow, it's PR-by-PR breakdown of activity. The DAG gives you the power to "explore the spiderweb" if want/need to, but also pull back and say "give me the high level over" (--first-parent). I still think a lot of the emphasis on rebase-only workflows would disappear if more of the graphic UI tools (including and especially GitHub) had a better --first-parent experience by default. With the GitHub PR flow it has always surprised me that the main commit log isn't just a --first-parent view with an optional drilldown experience.

Sorry to beat a dead horse, but I'd love to be convinced. Could you give me an actual example where you were able to review a commit log that had been rebased easier than it would have been had been merged? Or an actual example where a merged commit log was a pain where it would have been easier had it been rebased?

Maybe the advantage is for people who use graphical tools? I'm still in the stone age using Git in bash.

Thanks.

> I've tried the "rebase into a feature branch" workflow, which I think you are alluding to. Unfortunately, it always results in scary conflicts.

You never rebase something into something else, you rebase onto something. I suppose you meant you want to rebase feature branch onto master.

If you have conflicts, you'll have them anyway, regardless if you're merging feature branch into master, merging master into feature branch or rebasing feature branch onto master. Conflicts are not a consequence of rebasing.

I'm working in a feature branch, and after a day or three changes have landed in the main branch. Which I need to incorporate or my merge request will be behind.

When I pull from main (git pull origin develop) there are rarely conflicts. When there are they are easy to understand and fix. Clicking squash on my request hides all intermediate commits so history stays clear in any case.

When I try to rebase from main (git pull --rebase origin develop) often almost every file in the project is in conflict, and the conflicts themselves are incomprehensible. I then run rebase --abort and go back to the merge strategy.

I've tried this about four times in the last few years; no one is able to explain what went wrong. If I had to guess it may have something to do with me pushing the branch when creating it.

That's not how you do it.

    git checkout master     
    git pull             => fetch and merge the new things on master
    git checkout develop => go back to your work branch
    git rebase master    => simple rebase, no squash, no nothing. The conflicts are the same as you'd get with git merge

do not forget to force push the changes of your branch

    git push origin --force develop => to update your branch on the server

You can skip the "checkout master + pull" part by using "git fetch origin master:master", or by using just "git fetch origin" and then "git rebase origin/master". Other than that, that's pretty much my workflow too :)

Yes, I know. I just wanted to keep it at the simplest form.

Ok, thanks. Although making a one step process into five, doesn’t sound like a big win. Perhaps the shorter version is workable.

By "properly" - I mean not messing up your own or others work in unpredictable ways.

My dev team uses git properly. They are not some masters in a way that they know each command by heart. They often use visual tools or what is built into IDE. We just have general guidelines and everyone knows how to do basic moves like "get code from remote", "merge others work into your local changes".

We had people who always have problems like "GIT ate my homework", well they don't work with us anymore so maybe it is a selection bias.

But I don't think my team members were NOT studying git for months to get to that level, it just came as they go along. Visual tools help a lot really.

In the end I expect someone with any abstract thinking capabilities to be able to use GIT "properly" after a week of working within the team. Like pull new changes every day, create new branch, create a pull request, merge new changes into your working branch.

> By "properly" - I mean not messing up your own or others work in unpredictable ways.

The parent's point still stands: No one is out there choosing to use git in "unpredictable" ways.

No, if you have modicum of abstract thinking and spend up to 30 mins daily using GIT you don't use git in "unpredictable ways".

If someone is a software developer, for me basic requirement is having possibility to understand this.

The alternative is trying to use git while doing your best to avoid learning anything more about it than you absolutely have to, which is what most git users do. This is a great strategy for many tools, but git is not one of them.

> Of course people should learn to use git "properly". What's the alternative, that they should learn to use it improperly? Everyone should learn to use everything properly

No, its not. The alternative is not to.

Time is not free. Learning a tool properly is an investment. Sometimes that's worth it and sometimes its not. E.g. i would never advise anyone to take the time to learn dc properly.

> What's the alternative, that they should learn to use it improperly?

Yes. Or at least, avoid learning anything if they can help it, treating it as a black box that can never be understood. "Learn got properly" just means "actually make an effort to learn the tool rather that clinging to learned helplessness".

See my earlier comment here:

https://news.ycombinator.com/item?id=27580478

A viable alternative my coworkers seem to have adopted is, “Execute the git commands blindly as provided by me and get upset with git when something doesn’t work right.”

> What's the alternative

Perfectly explained here : https://xkcd.com/1597/

I think the point is is that it's worth learning it, subjectively speaking. People tell me to learn vim properly, but I really dont believe I'll gain much based on the sunk cost.

The alternative may be Mercurial?

Reply on news.ycombinator.com