New in Git: switch and restore

https://www.banterly.net/2021/07/31/new-in-git-switch-and-restore/

by todsacerdoti • 5 years ago

872 543 5 years ago

Thev00d00• 5 years ago

As a long time git user I absolutely love `git restore`. I hope that the ongoing improvements in porcelain will continue.

Vinnl3• 5 years ago

It's not really new anymore, but still way underused, so it could certainly do with more attention. Git's UI has become better, but they can't really remove the old UI and tutorials using those, so people keep sticking to that.

easygenes• 5 years ago

What would top recommendations be for tutorials using the newest UI?

Vinnl3• 5 years ago

We're commenting on one :) But really there's not much to it - `git checkout` is the main wart of Git's UI given how overloaded it is, and with `git switch` and `git restore`, you'll have banned out pretty much all of its regular use. And given how much more straightforward (i.e. they have more guessable arguments) those are, there's not as much need for tutorials anymore.

pcl• 5 years ago

It’d be interesting to add a config that disables the cruft for interactive terminals. I wonder if that could be a pathway towards deprecation.

agumonkey• 5 years ago

and it's a very general problem

distributing improvements after a large mass of old habits are spread around is something to be fixed

Omin• 5 years ago

I can't reasonably start using such functionality until the PC with the oldest software that I still use has updated or I will have to deal with 2 ways of doing things all the time.

Currently, that's an ubuntu 18.04 machine at work and that doesn't have `git restore`, yet.

coder543• 5 years ago

You could install newer versions of git using a ppa: https://launchpad.net/~git-core/+archive/ubuntu/ppa

makeitdouble2• 5 years ago

These new commands make a lot more sense, but the weird thing is they don’t bring anything else to the table. They behave exactly like the existing ones, so much that anyone that really cared could have just aliased them.

So is there any incentive to switch for the people who went through the trauma of burning the old ones in their soul ? (I often heard that knowing how it works internally makes git commands feel natural. I was lied to)

Vinnl3• 5 years ago

They don't behave exactly like the old ones, because they do less - which means it's harder to accidentally do the wrong thing, and it's easier to guess what its arguments do.

If you know the old ones already and don't make mistakes, it's fine not to use these, really. I consciously got the new commands into my muscle memory in case I'm pair programming or someone less familiar with Git is looking along.

And yeah, knowing how Git works makes it a lot easier to understand, but it doesn't make the commands more natural. (Except perhaps knowing when you can use a commit id instead of a branch name.)

onionisafruit2• 5 years ago

I had git-checkout syntax burned into my soul. I switched to switch/restore a year or so ago and am happy to be mostly unburdened of git-checkout. I say mostly because I still use it in scripts so they work with old git versions.

bicolao4• 5 years ago

You don't need -- as much in the "git restore" example. With git checkout it may be necessary to separate the branch and the paths with "--" but since "git restore" does not take a branch (except with -s), doing this is totally fine

    git restore test.txt

411111111111111• 5 years ago

It's usually not necessary for checkout either

yakubin5• 5 years ago

Not typing it with "checkout" gets in the way of good tab completion. At work we have at least tens of thousands of branches and if I hit tab after "git checkout file_path_prefix", my shell is going to freeze for a while, while tab completion is going over remote branches.

scotty79• 5 years ago

What does -- do exactly?

greatgib3• 5 years ago

Thank you very much for this info.

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.

chungy2• 5 years ago

-- is typically to end argument processing and to treat all further ones as files. With git-restore, it's probably only relevant if you happen to have files in your repo that begin with hyphens. A fairly unusual situation, granted, but not forbidden.

Denvercoder93• 5 years ago

For example having a space or a slash between repo and a branch in a command.

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.

manojlds• 5 years ago

Been there for about 2 years I believe.

golemiprague• 5 years ago

I wish git had some tree transversal related commands instead of all the crypto commands that nobody understand what they are doing without long tutorials. Got a feeling that this is a case where going down to the metal is better than all the abstractions.

talkingtab• 5 years ago

git restore, where have you been all my life?

lucb1e3• 5 years ago

Nonexistent for the most part unless you were born recently :)

Karsteski• 5 years ago

Good article. I've been using git switch since I started using git CLI a few months ago, but restore is new to me!

rubyn00bie• 5 years ago

I’m surprised no reference to:

git switch -

For going back to the previous branch you checked out.

hsn9153• 5 years ago

This is not new. It works the same with the checkout command.

    git checkout -

helltone• 5 years ago

What is a good resource to learn modern git properly? I have been using git for 10 years and get around with a really small set of old commands.

nerdponx• 5 years ago

Pro Git is excellent: https://git-scm.com/book/en/v2

SiebenHeaven• 5 years ago

Ah yes, modern git for people using modern c++ If your plain old git works fine for you, there is no need to go looking for modern git IMHO.

raju• 5 years ago

Agreed with the other recommendation of Pro Git.

If you want to learn Git from the inside out, I wrote a two-parter that aims to explain Git from the inside out, focusing on the data-structure Git uses:

https://looselytyped.com/blog/2014/08/31/gits-guts-part-i/

Finally, _if_ you have an O'Reilly subscription, I am currently writing Head First Git (first four chapters are in early release). If you are not familiar with the Head First series, its a rather unique format that involves using lot of pictures to explain ideas and traditionally the books move a lot slower than most technical books. Ideas/concepts are cemented using puzzles, quizzes, crosswords.

You can see a list of the existing ones here https://www.amazon.com/Head-First-Series-Books/b?ie=UTF8&nod...

Feel free to email me if you need any more resources—I have spent a lot of time teaching Git.

quantumsequoia• 5 years ago

Nothing has been more intuitive than this interactive online tutorial

https://learngitbranching.js.org/

You lean in 30 minutes more than you learn in hours of reading documentation and experimenting

some_developer• 5 years ago

I used to know lot of terminal commands but I'm seriously falling behind due to jetbrains integration which covers 99% of my daily use case. Together with local history, I've never "lost" work in years.

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.

600frogs• 5 years ago

I currently use a third-party git GUI (GitKraken atm) but I also use jetbrains products, am I missing out by not using the integrated git functionality? If so, is there a tutorial or guide you could recommend, or is it all fairly self-explanatory?

thecupisblue8• 5 years ago

Jetbrains Git integration is quite self-explanatory - if you're already using GitKraken, you're not missing out much except being able to do it from your IDE instead of another tool. Maybe conflicts are a tad easier due to same syntax highlighting style and ability to edit on the go.

AnthonBerg2• 5 years ago

The Jetbrains git interface is really quite good. For me the magic is the general combination of git and local history. The search is good and the diffing and jump-to-source from those. The changelist handling is pretty good too.

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

thecupisblue8• 5 years ago

but I'm seriously falling behind due to jetbrains integration

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?

phist_mcgee• 5 years ago

I think you're approaching git and software dev from a bottom up perspective. You learn the tools, understand why they exist, and then use the tools to solve higher level problems. Unfortunately due to time constraints, interest levels, and simply ease people go top down. They need to switch branch, so they will follow the least effort principle and use a UI. Barely understanding many fundamental tools is common these days for devs, and I honestly think that it's a sign that our field has grown massively in terms of the tools we need to use, the processes we use to deploy, and the products we use to develop. 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?

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.

papaf• 5 years ago

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.

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.

yunohn2• 5 years ago

This is an unnecessarily antagonistic rant, which boils down to “I know git from scratch, I’m so smart, why isn’t everyone else doing this”.

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.

wpietri11• 5 years ago

This attitude mystifies me. The whole point of computers is to solve problems well enough that most people don't have to understand the machinery.

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.

AnthonBerg2• 5 years ago

Might I ask what those git problems are? Thanks!

onionisafruit2• 5 years ago

My conflict resolution skills have atrophied due to jetbrains. It’s just so much easier than anything else I’ve tried. Even when I don’t already have a project opened in idea, I’ll open it just to resolve a merge conflict.

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

lucb1e3• 5 years ago

TL;DR because 'checkout' was found to be confusing, as of git 2.23 the switch command can switch to branches or commits (git switch master, git switch 0c38cf) and the restore command restores files (git restore pufferfish.txt).

cybersvenn• 5 years ago

Instead of one confusing command we now have three confusing commands.

lucb1e3• 5 years ago

I don't find switch or restore confusing? And also I never found checkout confusing, but that might only have been because I never realized it had multiple functions. I've been using it for both things (switching and restoring) for years, but I remember starting to read the article and thinking: how did I never notice this is the same command for two completely different things?! Maybe I used to know and now it's just not something I think about anymore? Either way, I can see how checkout can be seen as odd, but why switch or restore?

hsn9153• 5 years ago

I knew about `git switch` but this is the first time I hear about `git restore`.

It also never occurred to me that the checkout command was overloaded in that particular way.

thecupisblue8• 5 years ago

Doesn't seem overloaded, seems quite fitting. Checkout a hash or a file from a hash. Switch kinda seems "underloaded" in this way.

dilap• 5 years ago

It's definitely unintuitive for newcomers.

And I think arguably modifying working-directory files vs. modifying .git/HEAD are distinct things (though at this point I also find using checkout for everything to be pretty intuitive).

bobsterman• 5 years ago

switch being underloaded to checkout is the same as checkout being overloaded to switch.

In the checkout model, branches are just named aliases for their current hash. This seems trivial to me. Do we really need to use another vocabulary spot up in our heads for a command that is strictly a more-restricted checkout?

hsn9153• 5 years ago

Yea it never bothered me and I never understood why people kept complaining about it online. It seemed very superficial complaint.

The way you use git is by first understanding its model. If you understand the git model, everything makes sense.

If you come to it expecting it to be a tool that magically does what you want, I guess you will be very disappointed.

clon• 5 years ago

Another difference is that with git checkout you can create and switch to the new branch in one command using the -b flag:

  git checkout -b new_branch

You can do the same with the new one, but the flag is -c:

  git switch -c new_branch

A good example why developers should not try to be designers. Even of talking about "API/CLI design.

kzrdude2• 5 years ago

Developers/designers are always torn between the competing priorities of preserving consistency and making a new interface the best it can be.

yakubin5• 5 years ago

Apple and GNOME are even better examples of why designers should not try to be designers. Now what options do we have left?

CRConrad17• 5 years ago

Now what options do we have left?

KDE, git, and FreePascal / Lazarus.

rnestler2• 5 years ago

-b in checkout is short for "branch" while -c in switch is short for "create".

IMO the UI of git switch is much more intuitive, since the argument is always a branch and the default behavior is to switch to an existing branch. For slightly different behavior (like creating the branch first) there are flags.

So I think it's good that the flag for switch is a different one than for checkout, since the interface of git checkout was quite unintuitive IMO.

ahmedfromtunis• 5 years ago

The new command makes more sense to me, i.e. `switch` and `-c(reate)` new_branch.

With `checkout`, however, what does `-b` even mean? Branch?

That said, it'll sure take time before the majority of developers (including myself) get onboard with it.

Would a deprecation flag be a good idea for git?

CRConrad17• 5 years ago

The complaint has been, for ages, that checkout got that wrong. As designers, these developers are improving: They got it more right on the second try.

sparkling• 5 years ago

For more convenient git shortcuts, check out https://github.com/frostming/legit which plugs some extra commands into your git

mcs_• 5 years ago

Funny!

I've been using the alias `gk='git checktout'` for years now.

Git has been my first terminal-oriented versioning control system. I've used TFS and other but never focused on the action name, just the icons.

Checkout branch/hash/file seems more potent than two different commands.

cerved5• 5 years ago

I feel obliged to note that the version control of TFS (Team Foundation Server) is TFVC (Team Foundation Version Control)

kzrdude2• 5 years ago

It is unfortunate that:

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

the_biot• 5 years ago

So send in a patch.

vanviegen• 5 years ago

Your preferred solution to this inconsistency is for a random bystander to flip a coin?

asimpletune4• 5 years ago

I don’t know why this is getting downvoted. It’s the correct solution and actually a great opportunity to make an easy contribution to open source.

bobbyi_settv• 5 years ago

It's not just --help.

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 -

aryamaan• 5 years ago

I picked up git restore with git's suggestion itself.

Whenever I do git status, it tells me which files are changed and if I want to go back to their previous states, I can use got restore.

rnestler2• 5 years ago

For some time I was pretty annoyed that git was showing the new suggestions, but for some reasons my git autocomplete did not know about them and thus couldn't tab complete. (It was on ArchLinux with zsh using the grml zsh config).

After a few month the autocomplete got updated as well and I could actually use the new interface without to much frustration.

recursive2• 5 years ago

I've never seen the auto complete work with anything but file paths. Nor did I know it ever could.

tkfu• 5 years ago

This reminds me of the old xkcd [1] about how standards proliferate...

Situation: Git has 137 difficult and unintuitive subcommands [2], and new users can't keep straight which ones they should use.

"Oh man, that's awful, let's add new subcommands that are clear, and do just one thing well!"

Soon: Situation: Git's CLI has 138 difficult and unintuitive subcommands.

[1] <https://xkcd.com/927/>

[2] Yup, seriously, as of 2.32. I checked.

5e92cb50239222b• 5 years ago

Most of those are plumbing. They're only needed if you're building tools on top of git (integration with IDEs or custom GUI, for example), or doing very advanced scripting/broken repository repair.

ninkendo• 5 years ago

Except this is actually the opposite… they turned one command that did too many things into two commands which each do fewer things.

layoutIfNeeded2• 5 years ago

No thanks, I will keep using checkout.

leephillips2• 5 years ago

Me too. The checkout command makes sense and seems consistent to me: check out branches or files. Why do I need two other different commands for this?

layoutIfNeeded2• 5 years ago

Exactly. The way I see it is that “checkout” has two arguments:

- the commit you want to checkout, which defaults to HEAD

- the files you want to checkout, which defaults to everything

Simple as.

bicolao4• 5 years ago

The two are added with some extra protections. Something that cannot be done with git-checkout without breaking scripts.

I believe git-checkout could silently overwrite data in one case (can't remembe the details). And git-swith will stop you from moving the branch when you're in a middle of a rebase or other multi-command operations. It also tries to avoid entering detached HEAD mode by default.

It's definitely geared towards newcomers. But even I'm glad it catches me from doing stupid things from time to time.

philote• 5 years ago

I used to use Git Legit: https://frostming.github.io/legit/ But the official addition of git switch conflicted with their git switch (which is better as it auto-stashes changes before switching). Legit also had the issue of not properly handling branches with "/" in them.

hkopp• 5 years ago

My git productivity hack is `git diff --color-words`. Instead of showing the line-by-line diff, it shows only the words that changed. Especially useful if you have long sentences where only a comma changed or some other typo. With git diff, the two lines are shown, with --color-words, only the changed symbol is highlighted. The option --color-words also works with git show. I even made aliases for them: git cshow and git cdiff.

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.

mtekman• 5 years ago

In a similar manner for Emacs users: magit-toggle-refine-hunk is a lifesaver for word diffs

andreareina• 5 years ago

Key combo `D t`

leephillips2• 5 years ago

Thanks for teaching me about --color-words. I didn’t know about it, and I greatly prefer it over the normal git diff output.

lisper4• 5 years ago

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

yjftsjthsd-h• 5 years ago

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

richrichardsson• 5 years ago

What's the alternative

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

Shacklz6• 5 years ago

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.

ozim2• 5 years ago

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.

plorkyeran• 5 years ago

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.

web0073• 5 years ago

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.

bawolff• 5 years ago

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.

_6pvr• 5 years ago

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

papito2• 5 years ago

The alternative may be Mercurial?

Emanation• 5 years ago

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.

imiric• 5 years ago

I highly suggest delta[1] for viewing diffs on the command line. It pretty much replicates GitHub's diff rendering, and is quite configurable.

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

kevincox• 5 years ago

I am very happy with delta.

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

Liskni_si• 5 years ago

There's also diff-highlight[1] which is shipped with git itself and does almost the same thing, just possibly isn't as polished.

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

manexploitsman• 5 years ago

Tig - Text-mode interface for Git with basic vim bindings https://jonas.github.io/tig/

cush• 5 years ago

properly

Or maybe just don't shame people for not working the way you do.

CRConrad17• 5 years ago

If one guy says "This shit doesn't work!" and the other says "This is how it works", then it seems more like knowing how it works, well, properly than "shaming".

NilsIRL• 5 years ago

I also like to use `git diff --color-words=.` to do a character wise diff instead.

levzettelin• 5 years ago

Looking at diffs on the command-line is cute and all, but for anything substantial I doubt this will ever be as good as using a proper GUI interface. I like "meld". You have to install it, then run

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

and after that you can do:

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

mixmastamyk5• 5 years ago

It's good as the mergetool but overkill for a simple diff.

pjmlp6• 5 years ago

It is ironic that Linus hates C++ so much, and then proceeds to create what is for all practical purposes, the C++ of source control systems.

tonetheman• 5 years ago

This should be the top comment!

vnorilo• 5 years ago

Complexity is like body odor: you generally don't mind your own.

jeltz• 5 years ago

Git has not been Linus's project for many years.

hnarn• 5 years ago

To be fair, if you mean that these changes are “bloat” and that git should be kept “simple” (not easy but non-complex), I don’t think this has much to do with Linus, because as far as I know he’s no longer involved in the development of git.

necheffa• 5 years ago

I don't know, have you ever had to use Clear Case? git seems rather lean in comparison.

pjmlp6• 5 years ago

Yes, plenty of times and never had to redo my ClearCase configuration from scratch.

dboreham• 5 years ago

The Fortran of sccs surely?

thesuperbigfrog• 5 years ago

He was "scratching his own itch" (see http://www.catb.org/esr/writings/homesteading/cathedral-baza...).

Git was written to meet the version control requirements of the Linux kernel. It works well for that project's needs which are an outlier for most development needs unless you are working at FAANG scale.

PaulDavisThe1st14• 5 years ago

Git is a perfect match our project's needs, which are so far from FAANG scale that it would be a joke to even compare them.

In our case, fully distributed development (no developers live or work within 1000 miles of each other), public repository, welcoming 3rd party PRs, strong use of topic branches, fully rebase-not-merge workflow. 600k lines of C++, 21 year history, on the order of 100 contributors, 2-3 core developers at any point in time.

pjmlp6• 5 years ago

99% of developers that have to deal with git complexity aren't working at FAANG scale.

samatman5• 5 years ago

Kind of ironic to say "FAANG scale" here, since Google notoriously uses an enormous monorepo, and Facebook uses mercurial and has done considerable work to scale it.

chris_j• 5 years ago

What would you recommend using instead of git?

(Myself, I've been heard complaining that git is overly complex, but the source code control systems that I used to use before git include Subversion, CVS and various Rational products and I have no desire to go back to any of them.)

samatman5• 5 years ago

I can't recommend pijul, but I can recommend keeping an eye on it. Pierre-Étienne Meunier is a ferociously smart guy, and he's convinced me that patches are the correct way to build a VCS, rather than snapshots.

I catch up on a forum a few times a year, asking myself if it's ready for me to switch a repo or two over and see how it goes. So far I have to answer no, but I'm hoping it's just a matter of time.

pjmlp6• 5 years ago

If I had the choice just mercurial or yes, Subversion does just fine, it is anyway how 99% of people actually use git.

ylyn• 5 years ago

Git is very simple. It's the UI that is a bit messy.

C++ is by no means simple.

marcinzm• 5 years ago

Can someone tell me why they decided to have the new branch argument be `-c` in switch when it's `-b` in checkout?

Someone• 5 years ago

I would guess it is shorthand for —-create. A quick google confirms that (https://git-scm.com/docs/git-switch)

foxpurple• 5 years ago

Because c for create makes perfect sense while b does not make sense on a command which only works on branches.

chrisan• 5 years ago

maybe they regret the original `-b` and thought it should be -c for create as well?

ChrisMarshallNY• 5 years ago

These make a lot of sense. I have gotten used to the checkout behavior, so it isn't something I'm really pining for, but these are good.

ztcfegzgf• 5 years ago

both "switch" and "restore" say in the docs: "THIS COMMAND IS EXPERIMENTAL. THE BEHAVIOR MAY CHANGE."

so maybe wait until that note is removed.

aetherspawn3• 5 years ago

A lot of comments along the lines of ‘why do people use <ide> instead of learning the commands’.

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.

benglish11• 5 years ago

For me I’ve used visual git tools in the past and it ends up doing something unintended/unexpected. So now I only use the terminal commands. Perhaps the old git tools I’ve used have improved significantly though.

aetherspawn3• 5 years ago

I prefer to rebase on the terminal also, but I reference Sourcetree when doing it.

emsy• 5 years ago

I completely agree. It always baffles me how something so simple (yes, simple!) as version control can end up as the abomination that is git. After controlling for popularity, you don’t see nearly as much posts explaining subversion in detail, and subversion being centralized is neither the only nor the biggest reason for that.

gallier23• 5 years ago

No, version control is not simple, never was. git was the first vcs that didn't suck because it was the first tool that understood the nature of the problem. All others were ass backward and instead of solving the problem stood in the way and actively made things worse.

mikeyjk• 5 years ago

What VCS system is simpler? I've used mercurial, svn and git, and git seems the far easier of that sample space.

baq• 5 years ago

Wow, I’d never call version control simple. Actually it’s fiendishly hard. Git makes some simplifications (!) to make the problem more tractable.

crooked-v• 5 years ago

Git's basic problem is that it has a really a good model for the data, but a really terrible CLI.

oauea3• 5 years ago

All visual git tools I've used suck and wound up eventually corrupting the repo. Also I've noticed that all of my colleagues who learned git using these visual tools didn't actually learn git, and have no idea how to anything other than add/commit/push.

I say "just rebase your branch" and I can see the panic grow in their eyes.

toxik• 5 years ago

For these people, I think a manual backup is what they actually want. “If I fuck up so bad I have to roll back.” I don’t think it’s wrong necessarily either, and GitHub actually encourages this behavior with the easy Web file uploads. Many repositories are now 99% automatically created commits by drag and drop.

I think these people would be better served by a backup system where you can pin snapshots. They don’t really want to use VCSs like they’re meant to be.

quietbritishjim4• 5 years ago

I say "just rebase your branch" and I can see the panic grow in their eyes.

The irony of that is that resolving conflicts in a complicated multi-commit rebase is much more easily/efficiently done in a good GUI than on the command line. Not all GUIs support it though (I think SourceTree gives up if there's a conflict), in fact it's a bit of an acid test for a Git GUI. The Jetbrains IDEs (PyCharm, CLion, IDEA, etc.) work very well. (So does TortoiseHg but obviously not for Git!)

gallier23• 5 years ago

The only visual git tool I really like is gitextensions for windows.

intellix• 5 years ago

I wouldn't say I'm an expert but I've got about 10 years experience using git via CLI and whenever a noob does something weird and he's using an IDE I'm like... Sorry I have zero idea what this is trying to do and cannot help you

FunnyLookinHat• 5 years ago

I've had similar experiences with git or other tools - not being able to help a junior dev because the GUI they're using is obfuscating whatever it is the underlying tool is trying to do. I think the irony is that we've got this insanely complex version control system that actually could have several valid use cases for what is likely a common path for users in a GUI.

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

zwischenzug• 5 years ago

This is exactly what motivated me to write Learn Git The Hard Way - I was surrounded by people who depended utterly on IDEs and got themselves into terrible states that based on models that were refractions of what the the (universally available) CLI gives you.

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.

agilob5• 5 years ago

I feel you. I was recently hired to help with svn to git migration and Java upgrades from 5-7 to 8 (due to my previous experience with such migrations). When I joined they already had a plan. They told me no one will be using command line. They are currently discussing which GUI to use and everyone will have this GUI installed by default, git command will be discouraged as non-standard approach, windows users will not have git-bash installed. I was asked for recommendation of GUI tooling for git and I had absolutely nothing to say, the only I ever used was Kraken and that was in 2014?. When I offered to train and assist everyone with git command training to make everyone more efficient in industry standardised tooling, they told me that's not in the plan. My job was done there without me having to do doing anything, I was free to leave that job!

oli-g• 5 years ago

I understand that some GUIs sort of become "black boxes" while trying to abstract away the complexity, but I know at least one (Sublime Merge) that always shows you the low-level commands it's trying to run.

larusso• 5 years ago

Same for me. I switched from SVN to git professionally in 2013 and used git via Sourcetree on personal smaller projects. I had to switch to the CLI git because so used SVN also on CLI only and could not transfer the documentation to the buttons of Sourcetree. Whenever I help out other coworkers with git do it via commandline. Doesn‘t matter if windows or Unix. What drives me nuts with programs like Sourcetree is the fact that they apply their own default behaviors to make it „easier“ to use git. Like initializing submodules by default. I had a project with a sparse checkout scheme that could not be cloned via Sourcetree because of this. Our submodules where an optional compiler for a 3rd party platform.

smt88• 5 years ago

Good git GUIs (I use SmartGit and love it) do the following:

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

jbluepolarbear3• 5 years ago

I have 10 years of git cli and I use GitHub desktop or Sourcetree most of the time. I started using using a git IDE to help support the team members that weren’t experienced in git that chose to use one. I work in games and a lot of game developers mostly know Perforce.

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.

crazygringo5• 5 years ago

First of all, using "noob" like that is offensive. Everyone's a "noob" at some point. And if that's how you talk and treat people, I probably wouldn't want your help.

And second, what exactly mystifies you about what e.g. SourceTree menu commands do? They map clearly and intuitively to CLI commands.

If you have "no idea" what it's trying to do then you're not even trying to be helpful. You're just being condescending.

dagw2• 5 years ago

Isn't that just being incredibly lazy. Surely a reasonably experience person like yourself should be able to read the error message and at least get a rough idea about what the problem is. Then from there explain how you would fix it on the CLI and try to map that onto the GUI. Most Git GUIs map fairly closely to the underlying git model.

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

cannabis_sam• 5 years ago

This is my main gripe about git, it’s literally a tool created to suit the guy managing the linux kernel development via mailing lists… What proportion of junior developers are even tangentially working on anything resembling that?

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

detinho• 5 years ago

Specially when the ide doesn't use standard names and/or introduces new terms. Visual/ide tools to use git are welcome and I use them occasionally. But the cli should be the common denominator.

MarkSweep2• 5 years ago

What about staging lines to the index? I tried ‘git add -i’, but it feels pretty clunky compared to selecting some lines with a mouse in git-gui.

spkm• 5 years ago

I completely agree. At work we still use SVN, so I'm used to TortoiseSVN which is OK imo. Now for GIT there's TortoiseGIT, but it was such a bad experience. The TortoiseSVN background made it even worse, because things seemed similar, but did totally different things. So weirdly, for SVN I still use Tortoise, but for GIT, I prefer the CLI client.

dmz73• 5 years ago

If you are using a command line tool for 10 years and don't consider yourself an expert then either you are not using the tool very often or the tool is not well designed. In case of git I would say it is the latter. I mostly use git via tortoise interface and that works well 95% of the time. Other 5% is split between git mv, git branch -D, and trying various commands in order to make git do something simple that can't be done and then giving up. At this stage I see git as necessary evil rather than something that helps me with source version control.

ReFruity3• 5 years ago

That is true, but I think IntelliJ provides you with the list of commands it executed to get there.

tryingtogetback3• 5 years ago

For me, as a dentist, I used to use the dental drill, but now I trust my janitor to handle it, this way I make less mistakes myself

My job as a dentist isn't to use dental drill, it's to fix teeth in general. If I managed to fix a tooth and customer is happy, it doesn't matter whether I use drill myself or janitor does. Imagine having 100 complex things bouncing around your head and having to make that 101 when you forget the order of drill bits you need for a root canal.

The guy who knows dental drilling backwards is welcome to apply for a job managing dental drills or something if such a thing exists? But I could harp on the same way about his missing medical or braces-training skills.

zarzavat• 5 years ago

It's more like getting the dental assistant to operate the autoclave.

aetherspawn3• 5 years ago

If your janitor makes the client happy maybe he should retrain as a dentist?

madeofpalk• 5 years ago

At the end, it comes down to a personal preference of what you're most comfortable with. Some will prefer to use GUIs, others will prefer the command line.

Personally, I really enjoy using both the command line and the Github app. The Github app is super simple and straight forward, its great for just committing (parts of) files. Anything more than that and I prefer using the command line for "direct control".

akamoonknight2• 5 years ago

I will agree that visually seeing the tree is such a useful tool to have access to. I know that's not the true desire of your use case, but in case it's useful, I will add what is obviously the best git alias, 'git lg': https://coderwall.com/p/euwpig/a-better-git-log

git lg --all is probably my most used command in terminals and I think it gives me a better view of how projects are flowing on the whole.

res0nat0r• 5 years ago

I exclusively use git via the cli because guis are too confusing for me to keep track of what is going on, I also like to use tig to browse the commit history like above.

gallier23• 5 years ago

and the ultimate option for git lg is --reflog. Seeing all branches, even the old ones that do not exist anymore is a eye opening event in discovering the true nature of git: it never changes a commit, ever.

jamesmontalvo3• 5 years ago

If I need to visualize the network of commits I use this alias in .gitconfig:

network = log --graph --abbrev-commit --decorate --format=format:'%C(bold blue)%h%C(reset) - %C(bold cyan)%aD%C(reset) %C(bold green)(%ar)%C(reset)%C(bold yellow)%d%C(reset)%n'' %C(white)%s%C(reset) %C(dim white)- %an%C(reset)' --all

snarfy• 5 years ago

We are all using git only because Linus wrote it. The cargo cult is real and very much alive in our industry, I think precisely because we are all here to write specialist software. Too busy in our domain to worry about version control nuances so we just go with what is popular and don't think about it too much. It's not just version control, it's libraries, frameworks, languages, all of it. If it's not popular it's doomed to failure.

cerved5• 5 years ago

we use it because it's blazing fast, stable and extremely versatile

rbreaves• 5 years ago

You assume that the creator of one of the.. if not the largest open source projects on the planet might not understand the issue at hand better than literally anyone?

That seems arrogant. I imagine more thought & care went into git than you can fathom.

eloisant• 5 years ago

No, we use it because it's superior to the competition.

It's much better than Subversion that was the standard before git arrived.

And it's much better than Mercurial that was competing to become the source control system to replace SVN.

alerighi2• 5 years ago

True, a lot of people uses git without knowing how to use it, mainly because they do everything with a GUI and never learned how it works, and if something strange happens that can't be solved with the GUI they just delete the repo and clone it again.

At that point I say to these people, why you even bother with git? Just use what I call ".zip versioning", that is archive the source code an call it "project-vX.Y.Z.zip" and put it on the company fileserver.

Or better learn how to use git, and that means learning the command line and throwing out every gui (well, not all of them, for example I do commit and push/pull with VSCode, but when I have to do serious stuff like merging stuff I do it with the command line). To my experience GUI always cause problems than corrupt the history of the repository.

magpi32• 5 years ago

But he didn't write it. He started writing it in bash, and then (because he is Linus Torvalds), some very talented linux hackers jumped in to to help him. Just like with the kernel really. It was a tool written by extremely competent linux hackers for linux hackers, and that's why it is so successful.

emodendroket• 5 years ago

I find the visual ones often harder to use but that's just me. Whatever works works.

mberning2• 5 years ago

Absolutely. I can’t wait until something with better ux comes along and gets enough traction to make git a distant memory. I do not want to know the detailed inner workings of my VCS data model or 100 incongruent commands to make it work.

crazygringo5• 5 years ago

Seriously, seeing the commit tree laid out with colored lines is essential to me. A glance at the interface lets me know exactly what state the repository is in. Just like you say, it's less mistakes. Which is precisely one of the benefits of good UX.

Going from SourceTree back to the command line would be a huge step backwards for me. I still use the command line sometimes because there's advanced stuff SourceTree can't do. But for most of my basic everyday operations, the command line is just inviting me to make little accidental mistakes every so often because the state of the repository and branches isn't obvious at a glance.

I only see upside to using an IDE, zero downside. (I've never had SourceTree "corrupt" my repository, and all its commands do exactly what I expect -- it's just running the git commands I'd be typing out anyways.)

dvlsg• 5 years ago

Yeah, viewing a changeset and staging only some files or just parts of files is really important to my workflow. Sometimes I leave myself comments or skip tests locally and I have no intention of committing those changes. Using a tool like sourcetree to review, add, and commit only the lines I want is very helpful and saves me time.

I do use the command line for everything else, though. Well except interactive rebasing, I suppose. I pop back in to vscode for that. But even that gets started in the terminal.

Shorel2• 5 years ago

A couple of easily added aliases to .gitconfig and my CLI can do everything your GUI can do, in a portable way, and much easier and faster IMO.

Nothing to learn or even forget, either, as the CLI is actually the easier part of the job.

So, you do you, nothing wrong with that, but the CLI is here to stay.

magoon• 5 years ago

Commands are explicit and shareable. If you’ve mastered <ide> then good on you, but it makes you an island.

PaulDavisThe1st14• 5 years ago

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.

Imagine if you knew a cabinet builder who said:

"My job isn't to use a table saw, it's to build beautiful cabinets. If I get the cabinets built and the customer is happy, it doesn't matter whether I use a japanese handsaw or a CNC controlled laser. Imagine having 100 different pieces bouncing around around in your and having to then remember the assembly order."

Now, you might argue that this supports your point, by claiming that it actually doesn't matter whether the carpenter uses a japanese handsaw, table saw or CNC laser cutter. But I'd argue the opposite: it does matter whether the carpenter knows the tools they use as well as possible, because this will affect both the quality & speed of their work, but also the range of possibilities they can even consider. It doesn't matter much which tool they use, as long as they know it intimately and in depth.

I would argue that the same is true of the tools we use as software developers. Pretending that all of the skill lies only in the domain of creating actual lines of code is misleading. If you're using a revision control system, you owe it to yourself, your customers and your colleagues (if any) to be a master of that in the same way that you're a master of the specialist software you're creating.

wizzwizz45• 5 years ago

Version control isn't a tool I use. It's the filesystem I store my files in.

z77dj3kl2• 5 years ago

A more apt comparison would be to using a saw vs using a saw with gloves on.

With gloves it's safer and more comfortable, but you're not quite as in touch with the wood as you would be without one.

Without gloves you feel badass because you don't care about safety, and you might be able to carve out some slightly more intricate things.

Either way the outcome is roughly the same and it really doesn't matter what your personal preference is.

blub• 5 years ago

In your anecdote, git wouldn’t even qualify as a tool, it would be the weird storage space with an over-inflated sense of importance.

PragmaticPulp3• 5 years ago

But I'd argue the opposite: it does matter whether the carpenter knows the tools they use as well as possible, because this will affect both the quality & speed of their work

You chose a strange analogy, because CNC woodworking is far and away the superior choice over hand tools for producing cabinets. CNC cut and drilled wood is going to be orders of magnitude cheaper, more accurate, and allow the cabinet professional to focus on what really matters (installing them properly) rather than wasting huge amounts of time trying to do everything the manual way.

Ironically, this might be a great analogy to support the OP's point: Someone who gets so caught up in the tools and methods and doing everything the manual way for the sake of flexing their knowledge is at risk of wasting a lot of time and energy.

Personally, I have a lot of fun doing things the hard, manual way when I'm working on a hobby project. But when it's time to get work done, I choose the efficient abstractions and tools that let me focus on the core work without wasting time.

bostonsre2• 5 years ago

To the op's point, using git is not the act of coding or in this example making cabinets. I think it would be more akin to a work flow used by a cabinet maker and I think people would be less likely to look down on one that has an idiosyncratic work flow. It may not be the most optimal work flow, but they can get the job done well following their methods.

I don't subscribe to that thinking and I try to optimize and improve wherever I can, but developers are an idiosyncratic bunch. You can lead them to water or show them how to fish but lots of good developers just like to do things their own way.

6gvONxR4sf7o• 5 years ago

There are more things that reasoning applies to than you can learn, so it’s not really helpful in deciding between all the things. Everything depends on your goals and there’s no one size fits all answer.

escape_goat2• 5 years ago

It would be perfectly reasonable for someone to just say "no, I'm not going to imagine my job designing software as analogous to cabinetry," because argument from analogy shifts some of the burden of proof to the analogy itself, and the analogy must be defensible. In this case, you're drawing an equivalence between OP's 100 complex things and 100 cabinet components that must be assembled, yet also drawing an equivalence between the 101st thing and a central tool of the cabinet maker's trade. This is an internal inconsistency. You must either acknowledge the 100 things as 100 tools of cabinetry, each more important than the 101st, or you must regard the 101st thing as yet another fixture to be added to the cabinet. A domain expert is telling you that version control is a peripheral concern in their trade, the 101st tool, and you're responding with an idealism of mastery that stems from notions of integrity and identity and establishes no reasonable boundaries. You're welcome to this ethic and idealism, it's not a bad thing to have, but you're second guessing someone else's mastery based on arbitrary reference to your own mastery. I might as well be chiding you for looking up man pages without understanding the command-line capabilities of `troff`.

0xEFF• 5 years ago

I recently tried to help someone onboard into a cloud project that requires git tunneling due to security policies.

While they had experience with their IDE of choice and git, they were ultimately unable to push any changes.

nerfbatplz• 5 years ago

Except for 99% of all git day to day tasks are done with like 7 commands.

Git commit

Git checkout

Git merge

Git pull

Git push

Git rebase

Git stash

I can’t remember I needed a command that wasn’t one of those and I exclusively use the cli.

paulddraper• 5 years ago

I've used git for over a decade, and I can't think of anything new I've learned in the past 4 years.

And that last new thing was when git added worktree, which I don't actually use, but I learned about.

Contrast that with almost any other program....it's impressive.

adwww• 5 years ago

I seem to use cherry-pick at least monthly, as well as log and diff.

djmips• 5 years ago

It's funny but I forgot that Git restore was a new command, it only came in 2019 but I use it all the time.

gumby• 5 years ago

I don’t completely agree.

My job isn’t to use git, it’s to write specialist software.

I’m a big fan of automation, but there are certain fundamental tools I think one needs to understand to do the job. Both because you should have some idea what the automation is there to accomplish and also to get yourself out of a pickle when something goes wrong (or to even recognize when that happens!).

So, as I think most people would agree: you certainly don’t need to understand the obscure corners of your programming language, but you should have a solid understanding of the fundamentals and a decent overview of the rest.

In the case of source control, and git in particular, IMHO you should have a decent fundamental understanding (which isn’t even particularly complex at a conceptual level) so even if you don’t remember the command for ‘X’ , you’ll know to look for it when you do need it.

Given how you started your comment, perhaps you don’t even agree with implication of the sentence I quoted.

(edit: added IMHO)

GeorgeTirebiter• 5 years ago

How should one go about achieving a 'decent fundamental understanding' (specific pointers, if you have them). And, how much time must one devote to being a 'good enough git guru'? (and, it surprises me that gitless is not more popular: https://gitless.com/ )

stormbrew2• 5 years ago

I'd go even farther than not completely agreeing with that and just say that I completely disagree. Our job as programmers is not just to write a bunch of code in a vacuum, it is to create that code and communicate it to the machines and people who will be consuming and manipulating it.

Things like version control should be first class tools that we all learn in detail. They are literally the most fundamentally important tools we use every day if we work in a team. You aren't doing your job if you don't care about how your code interacts with your team and your deployment. Like an architect who doesn't know how to use a drafting table.

It's incredibly frustrating that people let their egos stoke them into this idea that tooling is beneath them. It's almost certainly the cause of an incredible amount of bad software, even though much of its code is, I'm sure, quite clever in a vacuum.

And I'd rather work with a hundred programmers who know how to use their tools than one programmer who looks down on them for it.

jupp0r• 5 years ago

Having been through two Perforce -> git transitions of medium sized repos with a few dozen people contributing and being the person with the most git knowledge in the group to be called in when people new to git mess things up: these GUI git clients are ok if you know what you are doing and what the consequences of checking various checkboxes are. They are not conducive to people learning how the tool git works and how to use it to solve real world problems. The command line is a great way to learn git and then fundamental understanding can be used to reverse engineer what GUIs do under the hood.

bob1029• 5 years ago

My job isn’t to use git, it’s to write specialist software.

This is true on so many other levels too. My job isn't to be an AWS expert, VIM master, Visual Studio ninja, Unix professor, et. al.

My job is to make the customer happy. That is it. If the customer is happy, my project managers are happy, the executives are happy, the investors are happy. When all of your bosses are happy, you can get away with absolute murder. No one gives you shit about anything. Production went down because you fucked up? No big deal - that was like the first time in 18 months we had any problems, and the customer can't even see these things through all the magical features get to play with day-to-day. Need to take the entire afternoon to play overwatch because [arbitrary fuck you reason abc]? No one cares as long as you didn't have a scheduled meeting. In this realm, your mind is free to explore side projects without fear of reproach or guilt-trip. Tasks are executed with confidence and calm. Innovations are more frequent and valuable. People are actually relaxing in their time off and enjoy working for their employer.

When the customer is pissed off, it is like entering into Doom Eternal as a non-player character. At every turn you begin to anticipate a heated conversation about missed target XYZ and incident ABC. Each ding of your outlook bumps your blood pressure by 20-30% before you even see the subject line. Your executives start taking damage from your customer's executives. Investors begin executing difficult queries regarding long-term viability. NO one is sleeping anymore. Side projects? Are you fucking kidding me? Not in this hell.

So, when someone in my organization starts giving me the run-around about [pedantic greybeard doctrine which adds 10x overhead to a process], and also has no business value to show for said run-around, I begin to shut things down pretty quickly. If you want to play nuclear release authorization simulator every time you need to check in source code, please do this on your own time. Even the most elite hacker rockstars like to use GUI tools so they can see what the fuck is going on without making their eyes bleed every 10-15 minutes due to terminal character display restrictions.

agilob5• 5 years ago

I expect other programmers to learn and master tools they use 50 times per day. You should be getting more efficient, productive and make fewer mistakes with languages, frameworks and tools you use daily. If you prefer sourcetree, be it, but I expect you to use it efficiently and not make mistakes other people wouldn't do with git, zsh and ohmyzsh (which contains like 100s of handy shortcuts).

u801e• 5 years ago

My job isn’t to use git, it’s to write specialist software.

Part of the job is to know and understand the tools that you need to use to in order perform the duties as part of that job. Saying that it isn't your job to use git is like a surgeon saying it's not their job to learn how to tie sutures when closing up the surgical site after completing the operation.

alerighi2• 5 years ago

You don't even need git at that point. I don't understand why using git if you want a GUI... at this point, put the source code on the company fileserver and adopt "zip versioning", i.e. when you do a new release create an archive named "project-X.Y.z.zip" and archive it on the fileserver. If you need to work on another branch copy the source code directory. Why bother at this point?

I don't understand people that wants to use git but they want do to so with a GUI that abstract everything that git was created to address, and they limit themself to write some code, commit and push. You are not gaining any benefit in using git this way, you are only wasting time to me.

If you choose to adopt git, you learn how to use it, and so you learn the commands (it's not that much effort). In my experience GUI always created problems, especially if someone in a team uses a GUI that creates junk in the repository (like 100 useless merge commits created automatically for things that shouldn't really have been a merge that make git log unreadable...).

Also people that uses GUI typically when they have a problem that the GUI doesn't know how to solve (because they typically implement the basic things and if something goes wrong they can't help you) just deletes the whole repo and clones it again, or worse they try to fix it by pressing random buttons in the GUI and put the repo in a shitty state so another coworker that knows how to use git has to waste his time cleaning up the crap that the fantastic git GUI made.

And I'm not saying that you shouldn't 100% use GUIs. I use the one of VSCode for doing simple things like creating commits, switching branches, and stuff like that. For advanced features like merge, cherry pick, rebase, whatever I use the CLI, I find it more practical.

MisterBastahrd• 5 years ago

Wonder how many command line enthusiasts are using gitflow to make things even simpler than sourcetree.

neop1x• 5 years ago

> My job isn’t to use git, it’s to write specialist software.

It's like a plumber complaining that his job isn't driving with a car and that he wants customers to pick him up or wait for him until he comes on foot or via public transport.

jonahx• 5 years ago

A fairer analogy is that GP is saying, "I don't want to use a van to bring my stuff, but prefer a pickup truck." From the customer's POV, it makes no difference.

mattrighetti• 5 years ago

Using git from cli is like driving a Ferrari in a road with 30km/h speed limit

smusamashah• 5 years ago

If you understand how git works, its data structure essentially, then its far easier to do anything with IDE/GUI instead of CLI. They are more intuitive and shorten the work and less prone to mistakes.

OJFord• 5 years ago

[I don't use git CLI so much any more] because I make less mistakes seeing the tree visually all the time.

I look at the tree visually so frequently it must be my most common command. In the CLI.

    log --graph --decorate --pretty=oneline --abbrev-commit

And then optionally adding whatever else, `--all` most frequently. (Obviously not writing it all out every time - with git config aliases, and actually `gitl` as a shell alias for that even. That's probably up there in my top.. 5? shell commands.)

GUIs work too of course. Just pointing out you don't have to abandon the CLI for a tree. There's fancier third-party tools than native git log that are still CLI even.

Arch-TK4• 5 years ago

So putting aside your argument that I completely disagree with but a lot of people have already voiced my concerns.

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?

Yes, this is the job of a maintainer in fact. They exist in a variety of organisations but maybe not enough. The best example is the linux kernel. Developers are expected to maintain their own local tree. When it comes to contributing code to the kernel, the patches are sent in a standardised manner to a mailing list and a maintainer then handles dealing with branches, rebases and merges. This means that developers don't need to know any more git than they really want to learn, aside from how to use git-format-patch and git-send-email which are really quite simple tools with an incredibly vast number of tutorials out there explaining them.

This means that people who insist that it's "not their job" to learn git can achieve the requirements of "patches which build at every step and contain isolated step by step changes" using a GUI or doing something really stupid like copying the code aside, deleting and re-cloning the repository and then pasting and committing each step. It also means that people who actually know how to use git can get the job done in a fraction of the time.

It also means that a carpenter^Wdeveloper's insistence to not learn how to use a claw hammer^W^W^Wgit will not affect their fellow coworkers/cocontributors.

alexott• 5 years ago

I'm using Git for a long time, but I'm still get back to the Magit for most of the tasks, except very primitive... Good UI helps a lot, especially for things like selective discard or commit

voidfunc• 5 years ago

The only git commands you need to know are: clone, checkout, pull, push, fetch, merge, and rm -rf $workdir.

tkuraku2• 5 years ago

I think sublime merge is pretty close to the optimal git GUI, https://www.sublimemerge.com/. It uses standard git commands and terminology and allows you to add custom git commands to the GUI. Unlike Sourcetree is cross platform for Windows/Linux/Mac and includes a merge tool. I think command line git and Sublime Merge git translate back and pretty easily.

elpakal• 5 years ago

+1 on cli git and Sublime Merge. I use cli for everything except viewing diffs and I find Sublime to be great at that.

rattray• 5 years ago

For those wondering this is a separate application from Sublime Text, built by the same folks, and with the same free evaluation and $99 lifetime license (not sure how "required" it is).

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

fermentation• 5 years ago

How do folks like this for reviews? I’m switching to git for a new job and the process is a bit overwhelming compared to mercurial

solarkraft• 5 years ago

I tried to use it and ended up back with Fork for some reason. I think basic tasks like merging were unnecessarily cumbersome and reliability wasn’t perfect.

tkuraku2• 5 years ago

Ive never had a problem, but use whatever works best for you!

biryani_chicken2• 5 years ago

I don't like Sublime Merge that much. Probably because I tried GitKraken first and loved it. It helped me understand stash and rebase better than the command line ever did. At some point they decided to not allow gratis use on private personal repos so I switched to VSCode with the Git Graph extension which gives me most of what I liked from GitKraken.

zoomablemind• 5 years ago

It's easy to become a periodic newcomer with service tools like Git, especially after an extensive dive into some complex new contexts. Simply speaking, I may forget the exact wording of Git (or other VCS) commands or switches.

However, what really sticks in my memory are the concepts Git implemented. This helps to refresh the operational knowledge rather quickly, well, notes help too.

In my view, 'check-out' as a concept is very much central to VCS as such. So, having a dedicated 'checkout' command which works on both commits/branches and files is quite reasonable - it keeps you in the same conceptual context.

I don't mind the specialized commands, such as 'switch' and 'restore'. But sure enough, I'll forget these wordings or maybe even mix them up with 'reset' or 'revert', ??'undo', yet the 'checkout' command would likely present itself on my command line as it's directly tied to the concept.

danjac• 5 years ago

If you are using the git plugin with oh-my-zsh you can type "gsw" and "grs" for "git switch" and "git restore" respectively.

aphroz• 5 years ago

git reset HEAD --hard or if it doesn't want to do it, I checkout another branch delete the old one and checkout back then use the local history from Jetbrain's IDE is my way to go. Probably not best practice but fast and efficient.

uses• 5 years ago

I use restore quite a lot but it kind of terrifies me that it can erase any amount of uncommitted work if I type something wrong. "git restore ." is basically "delete everything that I don't have a backup of".

rochacon• 5 years ago

Add `-p` (`--patch`) and then pick from the diff prompt what parts you want to restore. You can also use this flag with commit.

gigatexal• 5 years ago

I don’t know if it’s the article or me being a curmudgeon but I’m not convinced to switch. I grokk the checkout context aware semantics. I’m not switching.

Hackbraten• 5 years ago

These methods are still marked experimental, but for all intents and purposes they are here to stay

I’d love to see a source on that. Can experimental features not go away without notice at any moment?

whiddershins• 5 years ago

restore is a bad name for this action IMO. It is extra pandering to beginners, by targeting what the maintainers maybe believe is the most common use case.

Thats’s why checkout is such a great name.

Maybe ‘apply’ would be good.

My git-fu is often lacking, but I don’t blame git for being hard, I blame myself for not taking the time to be amazing at a tool basically everyone uses all day every day.

It’s silly not to know git. It might be the most used development tool in the world.

nine_k• 5 years ago

Once upon a time, someone decided to overload `checkout` with a bunch of semi-related actions, apparently for convenience. The day these patches were accepted was a sad day.

It's great to see that someone took time to restore sanity. I'll switch to these commands now.

stepanhruda• 5 years ago

‘switch’ to these commands, hehe

akx• 5 years ago

These features were introduced in 2019 (and have been featured in git's help texts since).

Serious question - Why is it that they're called new two years later? Is it that no one cares to read git's prompts or release notes?

jonwinstanley• 5 years ago

The author did say that had only recently discovered these commands. Unsure why they said they were new, maybe they were kidding?

CRConrad17• 5 years ago

"New" as in new to them, I'd guess.

erik_seaberg• 5 years ago

It might take five years for a change like this to show up on every box you log into, depending on how much your org relies on LTS releases to avoid randomly breaking stuff.

Lordarminius2• 5 years ago

As a helpful aside, in my experience, there are only about a dozen or so Git commands you need to do ninety percent of your work. You don't need to become a git zen master right away.

1. git init: to start a new repository

2. git status: checks your current state

3. git add -A: To begin tracking files

4. git commit -am: Commit all changes in the working directory with a message added on

5. git switch -c [branch name]: Create a branch and switch to it. (git checkout -b will do the same thing)

6. git switch [branch name]: switch between named branches

7. git merge[branch]: merge named branch into current branch

8. git branch [branch name] -D : delete branch if not tracked

9. git log --pretty=oneline: show a graph of commit history.

11. git push

12. git clone [repo]: Copy of a project/file onto your local computer.

The comments also contain some additional advice. Here is a good introductory video: https://www.youtube.com/watch?v=2sjqTHE0zok

TobTobXX• 5 years ago

8. git branch [branchname] -D : delete branch if not tracked

Dangerous advice there. Use the lower-case '-d' option. It'll tell you that you maybe don't want to delete the branch when it has unmerged commits.

If you really want to delete the branch then, the output of `git branch -d` tells you this option.

y04nn• 5 years ago

I would add `git rebase -i`, beacause I usually develop on a local branch and rebase it to the updated one. With git things can get messy when you want do something outside of the basic stuff. What I hate the most is resolving 3 way merges.

dfabulich• 5 years ago

Odd that you put switch on this list but not restore. Undoing changes is pretty important.

samatman5• 5 years ago

I'm mildly amused that your set of commands can't actually commit anything other than a brand-new file!

I will admit that I'm a lazy git user, and do most of my commits with `git commit -a`, rather than `-am` since I do try and give a short paragraph explaining the reasoning behind whatever the title message claims is the purpose of the commit.

I do run `git diff` first to see what I've changed, and if the diff has unrelated changes in different files I'll usually break it up into separate commits.

Decent introductory list, though. It won't surprise you that I think diff should be learned immediately; whether or not you need rebase depends on the conventions of the codebase, and if someone can learn it later they should, it can get tricky.

Lordarminius2• 5 years ago

True, an error. Corrected.

quickthrower25• 5 years ago

I’m interested in how many people double check their changes before committing as I’ve done this since the days of sourcesafe, and a decent number of bugs I’ve seen are people just not checking what they committed (some stray change got in that they never intended)

cryptonector3• 5 years ago

You're missing out. You need rebase and cherry-pick. Merging sucks.

quickthrower25• 5 years ago

Merging rocks! Never had an issue with merging and it’s less work. I’d only rebase if there is a “story” I want to tell in the commit history, that would be otherwise lost. This is rare, probably if someone else did some major refactor or move around

bigyikes• 5 years ago

If you’re a Git CLI user then I can highly recommend using SCM Breeze [1] which makes things a bit prettier and more convenient. It gives you a shorthand for various commands and improves default output formatting.

For example, ‘git status’ becomes ‘gs’ and it also gives you a numbered list of files. You can then substitute these numbers in place of file names in subsequent commands. No more manually typing names / paths.

Other examples are:

* ‘git add <file name>’ -> ‘ga <number>’

* ‘git add -A’ -> ‘gaa’

* ‘git checkout’ -> ‘gco’

[1] https://github.com/scmbreeze/scm_breeze

juped2• 5 years ago

They're several years old, but Duy Nguyen who invented them hasn't been around that much recently, which is why they're still marked "experimental".

bicolao4• 5 years ago

Well, I'm him :) I actually left Git. And it looks like nobody has picked it up since. So it's going to be forever "experimental" [1] until either someone starts doing something, or deletes the whole thing

[1] The experimental status is not because it's unstable but rather to allow us (or now, them) to change the UI design based on feedback if we got it wrong (again!).

juped2• 5 years ago

They are good features! I think they should just be made stable. Most of the help messages direct you to them anyway.

hrishi• 5 years ago

I have taken git apart and learned it three times now, and it all makes sense to me. The commands however, never clicked. The terminology never felt intuitive, nor predictably applied.

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.

ExtraE• 5 years ago

Is there space in the world for an all new (v2) set of porcelain commands? (IMO yes)

CRConrad17• 5 years ago

Is this perhaps exactly what "switch" and "restore" are -- the first of that new set? (I think they may be.)

adrianmsmith• 5 years ago

I like how these new commands are basically the same as the Subversion commands "svn switch" and "svn revert" ("git revert" obviously wasn't a possibility for this command as it was already taken).

Obviously Git and Subversion are different beasts but, if you only needed the functionality provided by Subversion, I always found the Subversion commands better named and easier to use. I'm glad that Git is slowly re-inventing these commands that Subversion had from the beginning.

FPGAhacker• 5 years ago

I see command line switches as an api, and it feels wrong to me to keep aggregating new things without a clean break.

I feel like these things should be versioned in some fashion. Perhaps come up with a clean slate api and enable it via calling git2 or git3 instead of this terrible mish-mash where new commands are constrained by previous bad decisions.

Of course this is not a novel idea, and people attempt this by making their own veneer with a different name… but this has to come from the top for it to be effective. People won’t en masse bother with git2 or git3 if it is not built into the mainline distribution.

I guess I should give it a try a submit a patch.

brundolf• 5 years ago

As with all successful software that's been around for a decade or two, git is too darn complicated.

To adapt the adage about democracy: git is the worst VCS, except for all the other ones.

niutech• 5 years ago

Try Gitless or Fossil - they are less complicated.

alkonaut10• 5 years ago

with git checkout you can create and switch to the new branch in one command using the -b flag: git checkout -b new_branch
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"

ReFruity3• 5 years ago

Well, maybe it indicates specifically that they had no meeting :)

eevilspock4• 5 years ago

The purpose of `git switch` is to switch branches, and its normal argument is a branch ref. Thus -b for "branch" would be redundant and confusing. -c is for "create", i.e. create the branch that i want to switch to.

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!

alkonaut10• 5 years ago

How does -b mean “create” in checkout? I get that it means “branch” but why is “branch” what I use to create a new one? The problem here is obviously the choice made for checkout, not switch. But consistency is more important so it’s better to keep consistency than “correctness” here imo. This problem already happened in the past with -d (delete).

notatoad• 5 years ago

i think they had a design meeting where they said "lets add some new commands to make git easier for newbies".

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.

alkonaut10• 5 years ago

Probably. But choosing the wrong-but-consistent flag would have been easier to learn and remember. I don’t think anyone will consider different git commands as old/new, or core/porcelain or whatever it is. I just want semantical “delete” to have the same switch name, for example.

afiori3• 5 years ago

That is probably what happened, with the observation that being consistent with checkout is a terrible idea for everything, as checkout is a clusterfuck of a command

cratermoon2• 5 years ago

Yea, all of us who have used git and learned to live with its quirks (and probably have Stockholm Syndrome from it) can chuckle a bit, but much of the git cli is a dumpster fire from the "principle of least astonishment" user perspective. The affordances in some cases are terrible.

Ever drive a car that had every function ever on one stalk? The one that's the turn signal also has the cruise control, radio, lights, wipers, and blinker fluid. Much of git is like that – context-sensitive.

I can't really fault the programmers, they (he) had a certain mental model and translated that concretely to commands. Except that the internal abstractions of how get works are orthogonal to tasks and use cases of users.

ReFruity3• 5 years ago

I love git even with all of its inconsistencies and complexity. May I recommend you an interactive tutorial (not mine)? https://learngitbranching.js.org/

biryani_chicken2• 5 years ago

I remember learning `git checkout` checked out files from a specific branch and the default behavior was to checkout all the files of the current branch and it made sense except for one thing. If I check out one file from another branch, HEAD is still pointing to my current branch, if I check out all but one file from another branch it's the same, but if I check out all files, then HEAD points to the other branch and that seems inconsistent. I always thought there should be one command that switched branches and then checkout changed the files.

CRConrad17• 5 years ago

But in your terms, a branch is the files it contains. Or rather: Changes gathered in a commit can be changes to several files. A branch is just a chain of commits, each based on the previous ones. So what a branch "is", is a bunch of (bunches of) changes to one or more files. Therefore, "checking out a branch" is checking out (a bunch of changes to) one or more files. And now you want to "check out one file from another branch"... Is it really any wonder that doesn't make much sense?

I think your doing yourself a disservice by even thinking in terms of "checking out a file" as separate from checking out a branch. The units git deals in are commits and branches, not really individual files as such. If you want to use it, better get used to thinking in the same units it does.

slaymaker1907• 5 years ago

My favorite part of switch is "git switch -" which switches back to the previous branch.

geenat• 5 years ago

Stupid since git checkout does the same things.

Git user since 2012 here.

CRConrad17• 5 years ago

Sorry, you were saying "git checkout is stupid since it does the same things", right?

(Only since 2014 myself.)

stevebmark• 5 years ago

One of the most common footgun mistakes I see in Git is people checking out a detached head state without knowing it, doing some work, then trying to push and immediately going to hell. I like that switch prevents this behavior by default. Also all git installations should come with a default shell prompt update so that it will show you immediately that you've gone into a detached head instead of a branch name. All git onboarding tutorials should include that instruction right after installing git.

gkilmain• 5 years ago

I like the git diff --color-words!

New in Git: switch and restore

Related Stories