Other than that, I recommend that people learn to use git properly. In my work, I often have problems with people overwriting their commits and trying to handle merge requests of commits where one commit message is "did some updates" and the other commit is "some fixes". Getting to know git for an hour, may have prevented both issues. But I am biased, since I use git since my bachelor thesis.

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

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

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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

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.

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

Thanks.

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.

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.

    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

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

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.

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.

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.

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.

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

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

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

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.

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.

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

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

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.

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

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

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

[1]: https://github.com/dandavison/delta

[1]: https://github.com/git/git/tree/master/contrib/diff-highligh...

I slightly tweaked the default config and it is great.

    [core]
     pager = delta
    [interactive]
     diffFilter = delta --color-only
    [delta]
     features = navigate
     hunk-header-style = omit
     line-numbers = true
     line-numbers-left-format = "{nm:>3} "
     line-numbers-right-format = "{np:>3} "
     max-line-length = 0

  git config --global alias.meld '!git difftool -t meld --dir-diff'

  git meld                   # like "git diff"
  git meld --staged          # like "git diff --staged"
  git meld branchA branchB   # like "git diff branchA branchB"

> You can do the same with the new one, but the flag is -c: git switch -c new_branch

It's like they had a design meeting where they discussed this and said "so I propose switch -b newbranch to create and switch to a new branch" and the objection was "nah that would make it consistent with checkout, which is against the project policy"

The whole point of adding git switch and git restore is to come up with more user friendly porcelain. Otherwise we might as well stick with git checkout. git checkout is maximally consistent with git checkout!

Because you can "checkout" other stuff too, not just branches.

> But consistency is more important so it’s better to keep consistency than “correctness” here imo.

Huh? I thought the whole point of these new commands was to try and fix the old illogical command line interface. Since one of the main problems -- probably the main problem -- is precisely the lack of consistency, the new ones logically just cannot be consistent with all the old ones, because then they would be just as inconsistent among themselves as the old ones. Something somewhere has to give. (And IMO this "-b" seems as good a candidate for the chop as any.)

But is that the case? Won’t this just be used in addition to the old commands (except checkout)?

The worst case would be adding commands that attempt to fix an UX but which don’t replace it, creating two separate UXes you must use at the same time. Anyone who uses the Windows control panel knows.

Dunno. (Elsewhere in this thread, the guy who built them reported that he isn't on the git dev team any more, so perhaps not too promising.)

> Won’t this just be used in addition to the old commands (except checkout)?

That's still a massive improvement, since checkout was arguably the main culprit. Also, it was never the case that you'd have to replace all git commands to achieve consistency: Many (hopefully most) already had consistent naming of arguments and options. So make your new ones compatible with the largest set of internally-consistent ones already present, and you only need to replace a minority. (Worst case, if all N were incompatible with each other, you'd have to replace N-1 -- but you could still keep one. :-)

Then there's also usage frequency to consider. Given that checkout is the command most inconsistent with others, often inconsistent even with itself, and among the very most used ones overall -- almost certainly, in my estimation, the most used of the candidates for replacement -- I'd say even if nothing more comes of this, it's a huge net win.

Also note that it's not a case of "two separate UXes you must use at the same time": git checkout is still there; no piece of the "old control panel" has -- AFAIK, or has any? -- been disabled or removed.

The only reason I bothered commenting is your comment pretty much called them stupid because their decision didn't line up with what you would have done.

The fundamental problem with this UX is that it (like so many Unix tools) doesn’t draw a hard line between interactive use and scripting use, so making large changes is out of the question since the interactive UX is already scripted in thousands of aliases and CI scripts. That’s a different topic though.

You're expecting the impossible. The current set of commands isn't great, everyone agrees on that, but they're too engraved in the minds of millions of developers to change. Thus, to solve the problem, the git developers come up with a new set of commands. By definition they won't be consistent with the current set of commands, as they're meant to solve the problems the current set has.

You have an issue with the new commands not being compatible, but you also have an issue with the old commands, that the new commands would replicate if they were compatible. What do you actually expect the developers to do?

If there is more to this retooling project than meets the eye (in this article) then great. My fear is that it’s more inconsistent aggregation, again - but it’s not obviously the case of course.

There are plenty of git wrappers that offer a cleaner API; you are totally free to use any of those, write your own, or to ditch Git altogether. Or is your beef with all of programmerdom, for choosing git as the platform for open source dev?

This is hacker news. It’s basically a few thousand armchairs. Welcome.

> You assume there is no design process.

I’m not saying that. I was just a few minutes ago explaining how I have tried to see traces of it. From the software itself there aren’t any obvious signs of (long term) UX design.

> the most successful VCS software in existence

Lots of stuff is wildly successful despite being an aggregated ball of mud (php, js, unix, c++…). Good (intuitive, consistent) UX is in no way required for popularity or success.

> There are plenty of git wrappers that offer a cleaner API; you are totally free to use any of those, write your own, or to ditch Git altogether. Or is your beef with all of programmerdom, for choosing git as the platform for open source dev?

The fact that none of them are popular I think is due to the problem with such extensions, that soon enough you have to write something portable (a CI script for example) that runs on vanilla git.

> Or is your beef with all of programmerdom, for choosing git as the platform for open source dev?

I like git, and I hate git. Git is simultaneusky hideous and awesome. I really really hope git isn’t the end of VCS, even though it’s now one of the better ones.

> your language has been more judgmental than concern

Fair point. I do enjoy pissing on things that look or feel Unix-y

Uh... Git was created by the guy who created Linux.

Initially to help manage distributed Linux dev. Not forced on anyone other than Linux devs. Not dominant through nefarious business practices like MS Windows, but because it spread *organically* overtaking other "well designed" systems. People voted with their feet.

Seems unreasonable:

* The problem with the "taped together ball of aggregated mud" is that commands and switches are illogical and inconsistent.

* These new commands are an attempt to fix that by introducing a set of (AIUI) parallel commands with better internal consistency.

* And now your complaint is that the new ones aren't consistent with the old ones?

No, of fucking course they aren't consistent with the old inconsistent ones. That's the whole point: If they were consistent with the inconsistent ones, they would also be inconsistent.

carrying over flags whose abbreviated forms don't make any sense in the new context doesn't make anything easier for anybody. if you want to keep using the commands you have memorized, you can do that - just don't use switch or restore. the new commands are different, that's the point.

    git restore test.txt

(Every non-official build is made from a separate branch.)

It's apparently a business requirement to keep every branch around forever, and I'll just take your word for that. At that point, you can have an `origin` remote where work happens, and the CI can include a push to an `archive` remote which is append-only.

Lets you have a development environment where the existence of a branch on origin means that it's in-play, and everything exists on archive if it proves needful.

Git checkout and a few other commands also use it to separate branch and the rest of paths, because you could specify like this

    git checkout branch path1 path2
    git checkout path1 path2
    git checkout branch # what if there's a file named "branch"?

    git checkout branch -- # always checkout a branch
    git checkout -- path1 path2 # always checkout paths
    git checkout branch -- path1 path2 # same, but disable disambiguation logic

From the article, I was thinking that it was again a stupid confusing design for the cli to requires the -- even with a dedicated command.

One main issue with git is to not be consistent and logic with the comments. Always to use different way or option abbreviation for different command. For example having a space or a slash between repo and a branch in a command.

  ls -file
  ls "-file"

Actually, this one makes sense, once you understand the underlying model of how git works with remote repositories, which (imo) is fairly fundamental to a distributed VCS.

They're different arguments (in your words, having a space) when you're accessing remote repositories and have to specify the location it should access. You can always substitute an URL for a repo in this case, and they fail if you cannot connect to the remote repository.

In all other cases (having a slash), you're referencing a ref in your local repository. This is a local copy of the remote repository. That means that it always works offline, but also that it doesn't sync with the remote repository. You can also substitute another ref, such as a "local" branch.

git fetch origin main

git rebase -i origin/main

Git push origin localBranch:remoteBranch

For example, why not:

git push origin/remoteBranch localBranch

(And if you want to preserve saying that slash is just for local, you could say: origin:remoteBranch)

So I can explain how git works in great detail, but ask me how to perform an action I haven't in a month, and it's a lot like figuring our a tar command.

+ git switch is documented as "EXPERIMENTAL"

+ git --help lists git switch but not git checkout as an important command

This is a documentation inconsistency. It can't be both the canonical interface to use and experimental at the same time.

When you checkout a specific commit and are now in detached HEAD state, you are by default given the message

    If you want to create a new branch to retain commits you create, you may
    do so (now or later) by using -c with the switch command. Example:

      git switch -c <new-branch-name>

    Or undo this operation with:

      git switch -

A much better response would be, "Thanks for pointing that out! I have filed an issue." One can't simultaneously through shade for not being community-spirited while expecting other people to do all the work.

In any case, the suggestion of submitting a patch when you notice a problem doesn’t deserve downvotes. That’s not throwing shade, at all.

If you do that work, I'm glad to try to help you see where their approach falls short in terms of sincerely encouraging contribution.

I'm not being coy, as if I really know what you think, but I'm asking anyway just to be frustrating. I mean, I have an idea, but I also didn't want to make assumptions about your intent, when it's just as easy to ask you to elaborate. After all, it's your point that it was incorrect, so I just wanted to know why.

Any way, you said there are "legitimate ways to suggest submitting a patch, but this isn't one" (I'm paraphrasing). To me that didn't really make sense, because that implies one of the wrong ways to suggest submitting a patch is to suggest submitting a patch.

> If that's really the case, then take a little time and explain exactly what impact you think that comment would have had on the person they were replying to

In my mind, it seems like the effect that it would have on them is to suggest to them to submit a patch. Alternatively, it might also have no effect, because they might not care enough to do anything about it, or just be busy, which is also ok. They don't have to listen to any advice, and it was given in good faith, without malice.

I can also imagine a situation where it is technically possible for someone to attribute all sort of weird malice to "so submit a patch" that wasn't actually there. After all, people can feel however they want. However, in my opinion it's quite rude to assume about someone without knowing them that they're such a fragile creature as to invent malcontent where there is, in my eyes, obviously none.

So going back to when I said "I have an idea", I meant that yeah I can imagine, after this back and fourth, that maybe you would assume something like this about someone else - that they can't hear "so submit a patch" without taking it en every wrong way possible - but I didn't want to make that assumption without at least giving you the opportunity to explain yourself.

Ok, on to exploring other ways to encourage them to submit a patch. You could say, "Do you know you can submit a patch?", "Feel free to submit a patch", "This looks like a documentation bug, would you submit a patch?". All of these also seem fine to me.

> If you do that work, I'm glad to try to help you see where their approach falls short in terms of sincerely encouraging contribution.

What I don't like about this, personally, is that you're convinced their suggestion wasn't sincere, as if there has to be an ulterior motive. As if believing that a programmer on a startup forum is capable of fixing a documentation bug is so crazy, there can be no other explanation than really they were trying to humiliate the other person.

Any way, I do believe that you're trying to be helpful and it's not really that big of a deal so no worries. Hope you can believe me when I say I'm being sincere as well. Basically, a lot of people have different ways of encouraging each other, and there are a lot of different styles of encouragement that people appreciate. It doesn't mean that one you don't agree with is wrong. When I read "so submit a patch", my mind didn't immediately go negative, and I hope the recipient of that didn't either.

If I wanted to actually invite somebody to contribute to an open-source project, I'd start with positive reinforcement. "Great point! That's definitely an issue with the docs." I'd then first tell them how to let the right people know about the problem. "You can file an issue here Be sure to categorize it as X, mentioning Y, and Z." Then I would explain that if they wanted to get involved in the project, they could try submitting a patch, giving them at least a few sentences of instruction on what files to look at, where to find the contributor guidelines, etc. In sum, if I'm asking somebody to do work, I'd encourage them and do a little work myself to show that I'm trying to support them.

And it's not just me. The "submit a patch" bit is a cliche bit of jerkiness, so much so that there are whole discussions of it. For example this: https://softwareengineering.stackexchange.com/questions/6874...

And this: https://softwareengineering.stackexchange.com/questions/8323...

And it's a long-standing problem in open source. This, for example, is more than 10 years old: https://xenoterracide.com/post/dont-say-patches-welcome/

So if that reply truly seems fine to you, please understand that if it ever was, it has been ruined by a long history of people acting like that to be dismissive or jerky. That rudeness is something I can almost excuse in someone actually working on an open-source project, as they can get a raw deal. But I think there's no place at all for it in a forum like this.

This means, here's my problem, someone else fix it for me. Since it has not been fixed for YEARS, maybe not the best alternative if you want to get it fixed.

Never heard of switch /restore and will probably forget about it the next time I'm on the terminal.

Rebase and interactive Rebase is so well integrated for my use cases and I feel much more productive without having to switch context.

Reflog and bisect are when I nowadays switch to the terminal, have not discovered an equivalent last time I checked.

This IntelliJ integration is the source of quite a lot of git problems in teams I worked with.

I'm quite flabbergasted by this - devs claim to know git on their CV, come in and know what "commit" is and how to use the IntelliJ UI, but don't even understand what its doing. And everyone is acting like it's OK and learning git is a "hard thing ill never need" and we should all use sourcetree or jetbrains. Or people just get so used to it and never understand what exists below it. They lose all sense of what they're doing and just think "the machine knows what I want". Then a vaguely questioned dialog appears - or something similar - and they cause clusterfuck upon their branch - or sometimes even other people's remote branches.

How do we allow our culture to be so lazy that people resist using one of the basic tools because "oh its hard I gotta remember 5 commands" and we find it OK? No wonder the plane is burning.

It's good that you still know that reflog exists, because a lot of "inteliij is my git client" users don't even know about it. Tho I'm still wondering, isn't it faster/easier to open intelliJ terminal and type a command or two than having to ope a whole new window and click around it? (also sorry if this sounds like an attack on you, it isn't! just really wondering!)

Also, re: OP: So basically 2 new commands were added that do what other commands already do, but people dont read the docs so we should add new commands so maybe people will read the docs for them?

Its probably a rhetorical question but I think its worth answering anyway.

Experienced developers had the luxury of learning git, say, over a 10 year period. I certainly know a lot more git than 10 years ago.

If you are a new developer thrown into your first real project and Intellij handles git for you so that you can concentrate on being productive then learning command line git takes a back seat.

I see this in many aspects of programming. One thing I am struggling with currently, is that JHipster generates applications in a user friendly way. JHipster is highly productive and seems like the future of programming BUT it means that there will be a generation of programmers that do not understand the MB of Spring Java code that is casually puked out by the code generator.

Its depressing to say it, but I think not understanding the tools is only natural and is probably the new normal in this age of complexity.

The depressing thing is I'm not talking just about off-the-shelf newbies, I'm also talking about experienced devs.

>Its depressing to say it, but I think not understanding the tools is only natural and is probably the new normal in this age of complexity.

Yes, unfortunately, this is becoming the new normal. But what is the next "new normal" after this? More complexity and obscurity? How long can we keep building that house of cards before it collapses upon us?

I use the basic git commands a lot but the wider set not very often.

So maybe I should learn Git from first principles every year? Like a cop would practice at the firing range?

But I’m doing that on my own time. But then what about the 1000 other things from Dockerfiles, to Relational database query plan optimisation, to the latest azure cloud offerings, to the newest React library for managing state, etc. etc.

The "cognitive burden" of git comes as much from the tasks that it is occasionally required to make possible than anything else.

If the only git commands you ever use are push, pull, commit and checkout then its a very simple system with very little cognitive burden. But one day, you may need to perform a truly complex task with git that a simpler system with much less cognitive burden would just not allow.

I do not understand how "data interchange formats" are an issue here. What do you want to inter-operate with?

Note that we're specifically discussing the theoretical reason for git's usability woes. The costs of actually fixing them in git aren't trivial, of course.

We'll see if JHipster and their ilk are really the new building blocks. A lot of the older RAD development tools have also gone the way of the dinosaur. For sure the new primitives will be higher level and allow us to build more complex applications, it's just a matter of time before we'll find our which ones have to most expressive power and ergonomics, and which turn out to be giant hairballs.

It is literally impossible for us to understand how everything we use works. We expect a compiler to just compile things and work; nobody is ranting about how modern developers are lazy because they can't hand-verify the compiler is outputting the right opcodes. Nobody is ranting about how web developers are lazy because they can't debug a browser runtime and its interface to the OS's rendering primitives. Can some people do those things? Sure. Do we imply character flaws for the 98% of developers who have focused on other things? No.

If this old-man-yells-at-clouds, good-enough-for-grandpa-so-its-good-enough-for-me style were the dominant approach in our industry, we'd still be working with punch cards and fanfold printer output. Thank goodness it isn't. Instead of having a million developers adapt to git, git should adapt to the million developers and free up their time for doing something that actually matters to a user.

How should git adapt? Can you get a simpler model than this? Is really a basic structure like a tree so complicated millions of developers are having a hard time with it?

Nobody is advocating for "dont use new stuff, old is betteer". Nobody is advocating for people to hand-check compiler outputs (unless your analogy pertains to people who work in a GUI tool that shows them pretty pictures for opcodes and they check if the pictures match).

You've missed the point.

The point is "try to understand the basics of the tool you are using".

If me wanting people to learn and understand more makes me an asshole, so be it.

I'd rather be an asshole and help people learn more and understand more than coddle them in the safety of the pretty buttons and say "it's ok, you don't have to understand".

If we don't understand our tools and the problems they solve, how will we make progress?

How will we make better tools?

How will we make better software?

How do you learn and grow if not by understanding what you don't?

That you can't tell the difference between "let's make software more usable" and "nobody should learn anything ever again and just soften into blobs of undifferentiated protoplasm" seems like a you problem.

Git is a very complicated, bloated command line. Frankly, most of the day-to-day can easily be done with a high level understanding and a GUI. There is no shame in not knowing the minutiae of git.

The goal of being a programmer is to produce cool things, not to duel with your tooling.

So much so that you can write your own basic version of git in a couple of hours: https://wyag.thb.lt/

Yes, you can write C without understanding poinnters, you can paint without understanding colors and how they mix, draw without knowing difference between 3H and 2B, use a drill without knowing which type of head is for what.

But try doing it long term and you either gotta learn those things or your output will be limited and clear expression of your vision will be harder.

I'm not advocating for people to learn git from scratch.

I'm advocating for understanding - not low level, at least high level.

And is it better to go through a "how to use X tool in Y GUI" tutorial or how to use "X tool" and then gain immediate understanding of what Y does? What if you switch GUI's? Which knowledge will be sticking?

The same applies to the git CLI. And really, to git. The right tool for a small group C-using kernel developers 15 years ago may not be the right tool for different people doing different things today. Let's hope it goes the way of C.

My experience is that knowing the DAG in GIT is equivalent to needing to know pointers to write effective C.

Knowing the internals is more like needing to know assembly in C. Yes, it can be really useful for debugging certain classes of problems, but not really necessary in day-to-day work.

I've used git professionally for 4 years now and haven't once run into a corrupted repo or a problem googling for help couldn't solve. Day to day driver is TortoiseGit, which is frankly just a shitty TortoiseSVN skin on top of git. But I like being able to visually see the graph since at the end of the day I'm doing graph operations when manipulating the repo.

It sounds a lot like you mean low-level, not high-level, though?

There’s more than enough to be achieved by just knowing the tree concept of git, and using a GUI to visualize it while running the basics - checkout, commit, branch, rebase, etc.

Oh, that's exactly what I meant. At least basic, high level understanding of the git model and basic operations on it. But most people never even get to rebasing or try do understand what lies behind magical buttons in the GUI.

It's hard to see the gaps someone else has, and wonder why they can't know what you know, but they may have some deep knowledge in a domain you are only superficially knowledgable in.

I agree we need to nail the basics, but this isn't 2002 anymore, and we don't ship Gold CDs to customers by running a build command on a single PC in the office. Our jobs are so much more complex and multi-faceted, and the oldbeard assumption that things are 'bare essentials' is eroded by the pragmatic realisation that we only have so many hours in the day.

You can use top-down knowledge to inform yourself on what concepts you need to learn, and you can ignore the parts of the domain you need right now. But you still have to learn them bottom up. Getting confused by the concepts you're using is a gigantic waste of time.

And the harder the concepts, the easier it is to get confused, so there's no trade-off.

Actually, I'm trying to look at it more from a "shallow sea" perspective - you have a problem and are given a tool to solve it. But do you not dive in just a bit to see "hey what is this tool" after you solve the problem?

Or after using it for a while?

UI is also something you have to learn how to use.

Sourcetree UI is as complicated as terminal for someone who never used it.

>I have to deliver products and deliverables, when and what do I focus on wrt gaps in my knowledge? Git? Unix commands? OWASP Security principles? Cache busting? global state management? ORM integrations with popular DBs? Kubernetes configs?

With that mentality, what do you ever learn?

Do you just keep on chugging year after year with "duct-tape the tools"?

Where is the joy in that? Where is the growth?

Are you always in a rush to deliver software without a moment to think?

You learn about the level you're using - like, are you using git daily? Just reading a tutorial or two and spending 5 mins a day with it in the terminal is going to do wonders for understanding it long-term.

>Barely understanding many fundamental tools is common these days for devs

It's common for someone starting to develop or starting to use a tool - hell, 8 years ago I have been as confused as "wtf is this git" as anyone.

Gradle was magic to me. Terminal was a dark and scary place.

That doesn't mean that it is okay to stay at that level.

If we accept "not trying to understand" as the new common, then we accept failure and ignorance as the new common.

We accept the world of broken software because people don't understand what they're doing - and we're telling them "you don't need to understand so don't even bother".

And hell, maybe that's gatekeeping, but fuck it, I'll rather be St. Peter at the gates than accept a world where learning and understanding is something "we don't have time for".

> With that mentality, what do you ever learn?

The way I understand it, this comment is saying you have to prioritize and work on the highest-impact areas. Of course you grow, but until a certain point you don't benefit much from knowing the guts of git more than Framework X.

I have never experienced any joy of creativity from using git, so it's not something I'm putting high on my list. Heck, learning Rust was 10x as good for my development as git, so I don't regret prioritizing that way.

I expect (hope?) that most people understand the git they use in their daily workflow... but that doesn't mean they have to have mastered every dark corner. Find a specialist (Stack Overflow :) when an unusual situation arises. If it's happening consistently, then I agree some more learning should occur.

>With that mentality, what do you ever learn?

>Where is the joy in that? Where is the growth?

>Are you always in a rush to deliver software without a moment to think?

There's nothing sexy about learning git commands for me

I'd rather spend that time on actual computer science fundamentals or even reading stuff like HTTP RFC than learning git quirks

The rest I do on the command line because I don’t want to forget — except commits because I’m not at risk of forgetting “git commit -m”.

I think a quick skim of the available features in the docs would probably give a good overview. Then poking around.

I haven't felt a need for a git gui but I might give this a try anyhow.

For me, I used to use the terminal git, and I still do occasionally. But I use Sourcetree now for most things because I make less mistakes seeing the tree visually all the time.

My job isn’t to use git, it’s to write specialist software. If I get the software written and the customer is happy, it doesn’t matter whether I use <ide> or not. Imagine having 100 complex things bouncing around your head and having to make that 101 when you forget the order of arguments to merge.

The guy who knows every command of git backwards is welcome to apply for a job managing a git repo or something if such a thing exists? But I could harp on the same way about his missing MATLAB or firmware skills.

I'm also not sure referring to people as "noobs" is going to help you empathize with their difficulty. ;)

I remember being in programming and software related IRCs at 10-11 years old having no earthly clue what in the fuck I was doing, asking adults questions and getting called a "noob".

Well, yeah, it was true. (I also made damn sure they had no idea I was a child.)

They could have said "inexperienced person" but that's not got quite the same ring and people are lazy, aye? Haha

Examples:

* https://en.wiktionary.org/wiki/noob

* https://www.etymonline.com/word/noob

Examples not containing the negative connotation:

* https://www.merriam-webster.com/dictionary/noob

* https://neologisms.rice.edu/index.php?a=term&d=1&t=2471

It might be something used quite differently by two similar groups, so it is good to be aware that other people may use it the other way.

Every problem I have to troubleshoot is almost by definition one I've never encountered before.

The best example of this was when I worked with a project with 12 dev teams that didn't rebase. They asked me where a commit came from, and when I ran 'git log --oneline --graph' the output was all pipes across my (maximized) terminal.

I've never seriously gotten into the 'plumbing' of git, so can't claim to have a 'true' vision of git via the CLI, but I've never yet been in a situation where it's been required.

Who defines which tools are "basic tools of the trade" and which are just bland infrastructure?

And who decides how much of each tool one should know to move beyond "daily incompetence"?

If I'm getting the job done and produce more net value than my peers for my salary, why should there be requirements on how well I know some specific tool?

I'm willing to bet a ton of value has been generated by folks who don't know the first thing about git beyond "commit, push, pull request". Who cares?

Now, of course, whatever my core job role is (perhaps it is firmware development, as in your example), I should know that role inside and out if my output is going into safety-critical places. But that's a different comment all together.

> Who defines which tools are "basic tools of the trade" and which are just bland infrastructure?

Well, if so many people routinely have so much difficulty with it as these comments witness, it can hardly be called "bland."

This is also why there was so so much fuss about git GUI client, there were looking for a golden hammer, a GUI that would do everything and anything.

Sometimes I read these things and end up saying to myself "Wow, that company just literally hates being productive"

The more tools people are allowed to install and use, the less standardised software development. Meanwhile we didn't even have common source code formatting pattern and single Java class could be formatted with tabs, 2 spaces and 4 spaces.

  EDITOR=joe git commit

I would never brush off a team member with “cannot help you”. I’m a git expert and I will figure out what’s wrong and fix it.

- use the same terminology as git

- show a log of every command

- default to sane behavior

- ask preferences instead of assuming (ex: rebase or merge?)

- show warnings when doing something destructive or unusual

I've found that I now spend zero time learning and thinking about git anymore, and it also protects our repos from git noobs at the same time.

- Want a diff between two commits from two different branches? Click one commit and Ctrl+click the other. All the diffs show up immediately.

- Messed something up badly and you need to see the reflog? Click the Recyclable Commits checkbox, and everything in the reflog shows up just like any normal commit. And you can use the diff trick above on them.

- Wonder what's in your stashes that you forgot about? Click the Stashes checkbox and they all show up as normal commits. Because that's what a stash really is.

- Committed something to the wrong branch? Drag the branch markers to where you want them.

Even if it’s exceptionally wonky, I have absolutely no problem introducing git to new devs, as long as it’s alongside a graphical representation (sourcetree or some ide-extension), and as long as I am able to enforce limitations on what commands can be run on the git CLI (or more realistically, disallow push to master, and force every merge/rebase through a review)

I’ve personally found that it’s trivial to understand how IDEs integrate git and then adapt the workflow around that, but it’s a complete clusterfuck to let self-proclaimed git wizards loose on a repo without any structure..

always did give me a chuckle how it took off the way it did for projects that don't come even remotely close to the scalability (like tree sizes) it provides.

the facts that it's free, fast, reliable, good for offline operation and can be used for huge and tiny projects alike are nice though. just never expected to see the day when web designers would become religious about using it.

So, hypothetically, if that were the case, what is the recommendation for Small/Medium web agencies?

On a more serious note, I wonder if GP ever worked on projects outside of large enterprises and is just gatekeeping it. Git is useful on solo projects, for God's sake.

HG is simpler to understand, has a more consistent CLI, and way better error messaging. Just a pity that it's been so sorely overshadowed by the Swiss Army Chainsaw of VCS.

Git can certainly do almost anything/everything anybody might want from a VCS, but, just like a chainsaw, it'll cut your leg off just as soon as it'll cut off the branch you're pruning if you're not fully expert in using it.

Why not just say the truth "I could help you, but it's not my job, so I'm not going to"

Maybe, but most Git GUIs don't provide clear error messages. This is the case of VSCode, which my teamates keep using. When you use Git CLI you can just have the original error message and know what's wrong.

I was also burned by sourcetree some years ago where it lost part of my code while doing a merge I didn't even understand.

I am not a Git expert. But I can remember the 5 commands needed to do my job every day: `commit`, `push`, `pull`, `rebase`, `checkout`. (you can also add `add` and `status` to the list if you want)

They're straighforward, except for `checkout` which is adressed by `switch` for the main usage.

If you use it wrong, Git CLI will tell you in most of the cases, and even tell you how to do what you intented to do. Git GUIs will probably tell you something wrong happened and left you at that or try to be more intelligent than you are and do something wrong.

> Isn't that just being incredibly lazy.

-> this is what I'd answer to do those Git GUIs.

> Isn't that just being incredibly lazy.

-> this is what I'd say to people who won't write these 5 commands on a sticky note or something and keep it for a month before realizing it wasn't hard to remember once you _commit_ to it and that Git is not hard, minus exceptional problems but Git GUIs absolutely won't help you with these exceptional problems.

What we need to do is get passed this ridiculous mindset some have that not knowing something is a bad thing. We all have to start off somewhere and “noob” is just a common term for describing that. Case in point: I’ll readily post “noob question guys, how do I…?” on Slack to give context that I’m asking a potentially basic question and basically don’t really know what I’m doing. For reference, I am the most senior on my team and yet I have zero issue highlighting stuff I don’t know when asking for help. And that’s exactly the way it should be.

There’s no shame in being new at something. What there should be is shame in wanting to mock newbies and shaming and those who don’t offer up their help to others. Being a noob should be celebrated as someone new joining the team rather than added to our dictionary of inappropriate terms.

Anyway, I’ve been the “resident git expert” before, and even just supporting competent CLI users is miserable once the team grows beyond 30 or so people. I can’t imagine trying to then reverse engineer and debug a half dozen crappy GUIs.

Optimizing everything around developers that can’t figure out the CLI sounds like a great way to attract bozos (both by admitting bozos and by chasing non-bozos out).

What about people who have totally figured out the CLI but still prefer to use a GUI?

I don't get why people act like it's either/or.