[HN Gopher] New in Git: switch and restore
___________________________________________________________________
New in Git: switch and restore
Author : todsacerdoti
Score : 649 points
Date : 2021-08-01 09:11 UTC (13 hours ago)
(HTM) web link (www.banterly.net)
(TXT) w3m dump (www.banterly.net)
| helltone wrote:
| 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 wrote:
| _Pro Git_ is excellent: https://git-scm.com/book/en/v2
| [deleted]
| quantumsequoia wrote:
| 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
| SiebenHeaven wrote:
| 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 wrote:
| 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/
|
| 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.
| FPGAhacker wrote:
| 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 wrote:
| 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 wrote:
| Try Gitless or Fossil - they are less complicated.
| pjmlp wrote:
| 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 wrote:
| This should be the top comment!
| vnorilo wrote:
| Complexity is like body odor: you generally don't mind your
| own.
| jeltz wrote:
| Git has not been Linus's project for many years.
| williamstein wrote:
| The Git commit history of Git is nicely browsable here: htt
| ps://github.com/git/git/graphs/contributors?from=2005-04-..
| .
|
| Indeed, Linus has only one commit in the last 3 years, and
| is the #28 committer of all time.
| sdesol wrote:
| Here is his contribution in the last 5 years
|
| https://public-001.gitsense.com/insights/github/repos?p=com
| m...
|
| The changes were mostly pretty small as well, which would
| make sense given he has been hands off for quite some time
| now.
| wpietri wrote:
| Analogy still applies, though. If a room is smelly to you,
| you aren't going to hang around. So the people who spend
| time there are going to be ones comfortable with the funk.
| chris_j wrote:
| 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.)
| samatman wrote:
| I can't recommend pijul, but I can recommend keeping an eye
| on it. Pierre-Etienne 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.
| pjmlp wrote:
| If I had the choice just mercurial or yes, Subversion does
| just fine, it is anyway how 99% of people actually use git.
| ylyn wrote:
| Git is very simple. It's the UI that is a bit messy.
|
| C++ is by no means simple.
| hnarn wrote:
| 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 wrote:
| I don't know, have you ever had to use Clear Case? git seems
| rather lean in comparison.
| pjmlp wrote:
| Yes, plenty of times and never had to redo my ClearCase
| configuration from scratch.
| thesuperbigfrog wrote:
| 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.
| samatman wrote:
| 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.
| PaulDavisThe1st wrote:
| 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.
| pjmlp wrote:
| There were other solutions, much less complex to deal with
| than git, but hey, they lacked the luxury of being an hard
| requirement to deal with Linux kernel and related eco-
| system.
| PaulDavisThe1st wrote:
| I've used, over the years, RCS, SCCS, CVS, SVN, Bitkeeper
| and Perforce. I would not trade any of them for git at
| this point in time, primarily due to the way that git
| allows for both net-connected and disconnected
| development without any change in the workflow.
| pjmlp wrote:
| I see you left mercurial out of the list.
| pjmlp wrote:
| 99% of developers that have to deal with git complexity
| aren't working at FAANG scale.
| dboreham wrote:
| The Fortran of sccs surely?
| bigyikes wrote:
| 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
| some_developer wrote:
| 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 wrote:
| 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?
| thecupisblue wrote:
| 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.
| thecupisblue wrote:
| > 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?
| yunohn wrote:
| 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.
| thecupisblue wrote:
| I don't know git from scratch, never written it or dived
| into source code itself.
|
| 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?
| yunohn wrote:
| > I'm advocating for understanding - not low level, at
| least high level.
|
| 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.
| thecupisblue wrote:
| >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.
| wpietri wrote:
| C is a great example here. If you write a lot of C, you
| really have to understand pointers very well. And quite a
| lot else. That makes it a bad tool for many purposes, so
| most developers do not use it, and fewer use it every
| year. It's just a bad tool for modern purposes.
|
| 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.
| Espressosaurus wrote:
| Except you don't need to know the git CLI except when
| you've screwed something up. Even the reflog is available
| via TortoiseHg. Bisect okay maybe you have to drop to the
| command line, but otherwise there's no reason to futz
| about it when you can checkout, merge, rebase, cherry-
| pick, create new tags, etc. using the GUI.
|
| 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.
| bspammer wrote:
| The irony with git is that the underlying data model is far
| simpler than the user interface implies. People assume git
| is complicated because the user interface is complicated,
| but it really is very simple under the hood.
|
| So much so that you can write your own basic version of git
| in a couple of hours: https://wyag.thb.lt/
| SAI_Peregrinus wrote:
| The problem is that git leaks the underlying data model
| all over the place, even where it's unnecessary to
| actually controlling versions. It's a nice data model,
| but the user view shouldn't expose it. The data model is
| an implementation detail, but git treats it like a show &
| tell.
| lanstin wrote:
| But this isn't a problem because the underlying data
| model is almost perfect for version control of text
| files. In some cases the data model is an implementation
| detail but in this case the porcelain is the fungible
| detail that can change depending on surface things like
| people's preferences.
| sofal wrote:
| You have it exactly backwards, and I think it gets to the
| core of why people get so unnecessarily confused about
| git. The underlying data model is both much simpler than
| the interface and crucial to understand. If you treat git
| as a collection of memorized command recipes the same way
| you did with SVN or CVS, you're going to have a bad time.
| The underlying DAG needs to be top of mind when
| interacting with git, as it best represents the inherent
| complexity of the problem that code repositories are
| meant to solve.
| wpietri wrote:
| 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.
| thecupisblue wrote:
| >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?
| phist_mcgee wrote:
| 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.
| thecupisblue wrote:
| > 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
|
| 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".
| tester756 wrote:
| I use GUI because it's infinitely times easier for me to
| check what changes I've done and to rethink them e.g
| trying to spot a stupid bug
|
| >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
| fn-mote wrote:
| >>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?
|
| 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.
| Kinrany wrote:
| I don't think going top down like this works.
|
| 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.
| papaf wrote:
| _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.
| thecupisblue wrote:
| >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.
|
| 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?
| joseluis wrote:
| the solution I believe would be to focus on creating
| simpler tools, and by that I mean tools with at least the
| same usefulness/as powerful as the ones we have now, but
| with much less cognitive burden, with better
| interoperability and composability by using simple
| standard data interchange formats.
| PaulDavisThe1st wrote:
| If you really believe this, then I don't believe that you
| understand what the job of a powerful revision control
| system is.
|
| 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?
| onionisafruit wrote:
| 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".
| uses wrote:
| 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".
| lucb1e wrote:
| 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 wrote:
| Instead of one confusing command we now have three confusing
| commands.
| lucb1e wrote:
| 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?
| makeitdouble wrote:
| Arguably there is some semantic overlap between restore and
| reset.
| hsn915 wrote:
| 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.
| thecupisblue wrote:
| Doesn't seem overloaded, seems quite fitting. Checkout a hash
| or a file from a hash. Switch kinda seems "underloaded" in this
| way.
| bobsterman wrote:
| 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?
| hsn915 wrote:
| 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.
| recursive wrote:
| I don't think magic is part of it. People like me just want
| it to be consistent.
| dilap wrote:
| 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).
| marcinzm wrote:
| Can someone tell me why they decided to have the new branch
| argument be `-c` in switch when it's `-b` in checkout?
| Someone wrote:
| I would guess it is shorthand for _---create_. A quick google
| confirms that (https://git-scm.com/docs/git-switch)
| foxpurple wrote:
| Because c for create makes perfect sense while b does not make
| sense on a command which only works on branches.
| chrisan wrote:
| maybe they regret the original `-b` and thought it should be -c
| for create as well?
| gigatexal wrote:
| 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.
| clon wrote:
| 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.
| kzrdude wrote:
| Developers/designers are always torn between the competing
| priorities of preserving consistency and making a new interface
| the best it can be.
| yakubin wrote:
| Apple and GNOME are even better examples of why designers
| should not try to be designers. Now what options do we have
| left?
| rnestler wrote:
| -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 wrote:
| 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?
| alkonaut wrote:
| > 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"
| ChrisMarshallNY wrote:
| 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.
| alexott wrote:
| 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
| Thev00d00 wrote:
| As a long time git user I absolutely love `git restore`. I hope
| that the ongoing improvements in porcelain will continue.
| zoomablemind wrote:
| 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.
| Vinnl wrote:
| 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.
| makeitdouble wrote:
| 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)
| onionisafruit wrote:
| 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.
| Vinnl wrote:
| 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.)
| easygenes wrote:
| What would top recommendations be for tutorials using the
| newest UI?
| Vinnl wrote:
| 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.
| Omin wrote:
| 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 wrote:
| You could install newer versions of git using a ppa:
| https://launchpad.net/~git-core/+archive/ubuntu/ppa
| pcl wrote:
| 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 wrote:
| and it's a very general problem
|
| distributing improvements after a large mass of old habits are
| spread around is something to be fixed
| danjac wrote:
| If you are using the git plugin with oh-my-zsh you can type "gsw"
| and "grs" for "git switch" and "git restore" respectively.
| Hackbraten wrote:
| > 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?
| sparkling wrote:
| For more convenient git shortcuts, check out
| https://github.com/frostming/legit which plugs some extra
| commands into your git
| bicolao wrote:
| 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 wrote:
| It's usually not necessary for checkout either
| scotty79 wrote:
| What does -- do exactly?
| bicolao wrote:
| -- in git is usually used to mark the end of options. After
| --. --foo means an argument --foo, not the option --foo.
|
| 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"?
|
| -- help disambiguates that by being between the branch and
| the paths, so git checkout branch -- #
| always checkout a branch git checkout -- path1
| path2 # always checkout paths git checkout branch
| -- path1 path2 # same, but disable disambiguation logic
| MawKKe wrote:
| it is used for that purpose in many other tools as well
| (grep, for example)
| yakubin wrote:
| 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.
| Freak_NL wrote:
| How do you end up with that many branches? It sounds like
| you keep every feature branch around forever. Keeping one
| around for a few months I get (although personally the
| sooner they're gone after rebasing or cherry-picking them
| the better), but this sounds like a full on history of
| every branch ever.
| yakubin wrote:
| If someone pushed a branch to remote, then there is a
| chance that they made a CI build for a customer based on
| that branch. Later you may need that branch to look at
| the source code, when you get a coredump, or logs or
| something.
|
| (Every non-official build is made from a separate
| branch.)
| samatman wrote:
| You may not have much choice in the matter, but this
| level of complexity is where I would strongly recommend a
| (slightly) more complex architecture.
|
| 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.
| Freak_NL wrote:
| Deployed versions that need to be referred to later
| usually get git tagged, but those are not that much
| different from branches of course (they'll both show up
| in autocomplete as a committish object). But even then;
| tens of thousands of tags/branches? At that point it
| might be worth considering simply baking in the git
| commit hash into the build artefact for future reference
| instead of tagging every CI build with a branch/tag.
| yakubin wrote:
| When I say "non-official", I say that it has some commits
| that aren't on the main branch. You need to push them
| somewhere, or else they're going to be lost.
| [deleted]
| greatgib wrote:
| 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.
| chungy wrote:
| -- 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.
| mcs_ wrote:
| 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.
| cerved wrote:
| I feel obliged to note that the version control of TFS (Team
| Foundation Server) is TFVC (Team Foundation Version Control)
| kzrdude wrote:
| 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.
| bobbyi_settv wrote:
| 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 -
| the_biot wrote:
| So send in a patch.
| asimpletune wrote:
| 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.
| wpietri wrote:
| It's not the correct solution because it requires knowledge
| of the intent of the project leaders, which is not easily
| available to us.
|
| 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.
| asimpletune wrote:
| Submitting a patch would start with filing an issue
| right? And I assume in that venue the maintainers would
| clarify their intent. If help were indeed needed then I'm
| sure the maintainers would be relieved to get some help
| fixing the documentation but.
|
| 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.
| wpietri wrote:
| There are ways to suggest submitting a patch that don't
| come across as dismissive, as a way to shut down a
| legitimate complaint. But this wasn't one of them.
| asimpletune wrote:
| Ok, and why is that?
| indymike wrote:
| > "Thanks for pointing that out! I have filed an issue."
|
| 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.
| vanviegen wrote:
| Your preferred solution to this inconsistency is for a random
| bystander to flip a coin?
| cratermoon wrote:
| 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.
| manojlds wrote:
| Been there for about 2 years I believe.
| juped wrote:
| 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".
| aryamaan wrote:
| 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.
| rnestler wrote:
| 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.
| recursive wrote:
| I've never seen the auto complete work with anything but file
| paths. Nor did I know it ever could.
| golemiprague wrote:
| 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.
| Lordarminius wrote:
| 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
| y04nn wrote:
| 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.
| cryptonector wrote:
| You're missing out. You need rebase and cherry-pick. Merging
| sucks.
| samatman wrote:
| 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.
| [deleted]
| Lordarminius wrote:
| True, an error. Corrected.
| TobTobXX wrote:
| > 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.
| dfabulich wrote:
| Odd that you put switch on this list but not restore. Undoing
| changes is pretty important.
| voidfunc wrote:
| The only git commands you need to know are: clone, checkout,
| pull, push, fetch, merge, and rm -rf $workdir.
| talkingtab wrote:
| git restore, where have you been all my life?
| lucb1e wrote:
| Nonexistent for the most part unless you were born recently :)
| hrishi wrote:
| 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.
| tkuraku wrote:
| 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.
| solarkraft wrote:
| 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.
| tkuraku wrote:
| Ive never had a problem, but use whatever works best for you!
| rattray wrote:
| 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 wrote:
| 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
| elpakal wrote:
| +1 on cli git and Sublime Merge. I use cli for everything
| except viewing diffs and I find Sublime to be great at that.
| aphroz wrote:
| 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.
| whiddershins wrote:
| 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.
| ztcfegzgf wrote:
| both "switch" and "restore" say in the docs: "THIS COMMAND IS
| EXPERIMENTAL. THE BEHAVIOR MAY CHANGE."
|
| so maybe wait until that note is removed.
| aetherspawn wrote:
| 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.
| PaulDavisThe1st wrote:
| > 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.
| bostonsre wrote:
| 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.
| PaulDavisThe1st wrote:
| It's about _tools_. Git (and revision /version control more
| generally) is a tool available for you to use when
| developing software. The questions for me are: do you use
| the tool? do you understand the tool?
|
| I think it's fine if someone says "I don't use that tool".
| I personally think that they are making their life harder
| and their software probably worse, but that seems like a
| valid choice. What I have a difficult time with is someone
| who says "I use that tool, but I limit my understanding of
| it to be as little as I can, because understanding my tools
| is not part of my job". That's what I felt the OP was
| doing.
| bostonsre wrote:
| Surely some tools have to be more important than others
| tho and not knowing some tools impacts some jobs less. Is
| git a saw for woodworking? Or is it a tool chest that has
| a drawer for a saw? If you need to use a thousand
| different tools, the tool chest becomes more important
| (the analogy doesn't map well there but it seems similar
| to working on a bunch of repos that have a bunch of
| branches or one repo with one branch). If you only need a
| handful, it seems like it would impact your job less.
| 6gvONxR4sf7o wrote:
| 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_goat wrote:
| 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`.
| PaulDavisThe1st wrote:
| > A domain expert is telling you that version control is a
| peripheral concern in their trade
|
| 1) I have no way of knowing if they're a domain expert.
|
| 2) With 35 years of software development under my belt, and
| a half dozen version control systems too, I'd consider
| myself likely to be as much of a domain expert as the OP,
| and I'm saying the opposite.
|
| 3) I am not as master woodworker. I have built cabinets and
| many other things. Philosophically I consider the
| disjunction between our culture's attitude towards physical
| tools (where there's an assumption that one will have to
| take time to learn how to use the tool before actually
| being able to make anything good with them) and digital
| tools (where there's an assumption that apprenticeship
| should be kept to a minimum, preferably zero) extremely
| interesting.
|
| 4) When I'm working on a task (I also build very
| specialized, highly complex software) the distinction
| between the cognitive load caused by the task and the
| cognitive task caused by the tools I have available to work
| with is not very big. It doesn't make much different
| whether the "101st" thing concerns a tool or a component,
| it's just another part of the big picture that I have to
| struggle to keep in my head as I move forward.
| escape_goat wrote:
| This is an excellent reply, more interesting than my
| comment, and I certainly cannot gainsay you. However,
| '100' might as well be 'n'. Your reply suggests that
| there is a struggle to maintain contextual awareness of
| 'n'. In this model, for everyone, there will be an n+1, a
| necessary factor where the diminishing returns of mastery
| do not justify the cognitive load. I do not think the
| heart of your dispute truly lies so much his model of
| peripheral necessities as with his ranking of git as an
| n+1 tool.
| wizzwizz4 wrote:
| Version control isn't a tool I use. It's the filesystem I
| store my files in.
| foepys wrote:
| This is only true until the first merge conflict or when
| you want to know when a bug was introduced to even find its
| location.
| ithkuil wrote:
| I interpreted what GP said as " the version control
| system is the place I store my files, so it's not just a
| tool, but it's an essential and necessary environment,
| the space where I organize my stuff"
| wizzwizz4 wrote:
| That's more what I was going for. It's also part of the
| background, as opposed to something I deliberately
| interact with, so I don't use it _like_ a tool in my day-
| to-day.
| wizzwizz4 wrote:
| All things I know are possible. I understand Git's
| _architecture_ , just like I know what an inode is. I
| could re-implement my own (bad) version control system,
| if I wanted to, just like I could make my own (bad)
| filesystem.
|
| But that doesn't mean I need to have memorised the CLI
| invocations. There's a button in Git GUI for all the
| things I need to do (including the things you've listed),
| and in the rare case where I need to do something else
| (e.g. submodules), I can look it up, just as I do in the
| rare case where I need to make a symbolic link.
| alisonkisk wrote:
| I resolve conflicts in GUI every week.
|
| I find the location of a bug by running tests and looking
| at the code.
| PaulDavisThe1st wrote:
| git bisect will optimize the number of tests you have to
| run, and will reduce the amount of code you have to look
| at it to the minimum (in general).
| wizzwizz4 wrote:
| Assuming a binary search over version history is a valid
| way of finding the bug. If you have a better idea of the
| probability distribution (e.g. it _might 've_ started
| being buggy any time in the past year, but I'm fairly
| sure it happened about nine months ago when the
| formatting of the report broke a bit) you can do a better
| job manually than `git bisect` - and if the bug is
| actually _multiple_ bugs, or other things changed that
| affected the bug 's presence or absence (making it appear
| or disappear in non-trivial patterns between versions),
| `git bisect` will mislead you.
|
| `git bisect` _is_ pretty cool, but "knowing your tools"
| isn 't the same thing as "memorising the man pages".
| PaulDavisThe1st wrote:
| if you are confident that it happened about nine months
| ago, then just start the bisect bounded by age-
| appropriate commits. just a case of knowing your tools ;)
|
| yes, if the bug is a complex interaction of several
| different code changes, and comes and goes, then a binary
| search will not find it. however, it may be the fastest
| way to realize that it _is_ this sort of bug. recognizing
| patterns in what happens when you use git bisect is
| another aspect of knowing your tools, and in this case,
| will help you move more rapidly toward a more appropriate
| approach.
| ekster wrote:
| Would you use an accountant who doesn't think it's
| important to know how to file documents, or that their file
| cabinets are even a tool of the trade?
| z77dj3kl wrote:
| 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.
| erikpukinskis wrote:
| I flagged this because this is extremely dangerous advice.
|
| DO NOT use gloves with a table saw, jointer, etc
|
| There are exceptions, but if you want a simple rule: DO NOT
| use gloves with power tools
|
| It is extremely dangerous. You can take an injury that
| would've been a nick on the finger and turn it into a lost
| hand.
| z77dj3kl wrote:
| I had a hand saw in mind...
| PaulDavisThe1st wrote:
| Speaking as a person who lost half a thumb to a table saw
| ...
|
| the difference in your analogy emerges when someone
| wants/needs you to carve out something more intricate, and
| you say "it's not my job to be able to do this without
| gloves".
| blub wrote:
| 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.
| PragmaticPulp wrote:
| > 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.
| PaulDavisThe1st wrote:
| If you have a CNC system, then I'd say you should
| absolutely be using that in preference to other things. But
| you should also come to as deep an understanding of the CNC
| system as possible, so as to be able to grasp what you can
| do with it, and how you could use it to carry out specific
| tasks that might arise in the course of your work.
|
| What you should not do, IMO, is to say "Oh, I have a CNC
| system, but I never interact with it directly, I let CNC-
| Foo on my computer control it whenever I need to do
| anything".
| PragmaticPulp wrote:
| > What you should not do, IMO, is to say "Oh, I have a
| CNC system, but I never interact with it directly, I let
| CNC-Foo on my computer control it whenever I need to do
| anything".
|
| I have experience with CNC machines, and I would still
| not recommend that anyone try to control their CNC
| machine by typing in G-Code directly. Understanding
| G-code can be helpful, but you really need to learn to
| use the higher-level tools properly to get anything done.
|
| HN is really strange on the topic of knowing the
| underlying details of complex systems:
|
| - When the topic of CS interviews comes up, the comment
| section is irate that companies are testing for low-level
| knowledge that isn't used in day to day programming
| tasks. Asking someone to reverse a linked list is
| blasphemy because we have libraries for that.
|
| - When the topic of Git comes up, the comment section is
| insistent that the only possible way to use tools is to
| have intimate working knowledge of the underlying low-
| level concepts. Insisting that people know the ins and
| outs of every git command instead of using a GUI is the
| only acceptable option.
|
| I suspect there's a lot of overlap between the two
| positions, which boils down to: "I do things a certain
| way and I'm convinced my way is the correct and only
| way."
| PaulDavisThe1st wrote:
| 1) I don't think it ever makes much sense to have a
| concept such as "HN is really strange on ...". This place
| is a collection of thousands of individuals, and you're
| going to see a wide range of opinions, many of them
| contradictory. Since not everyone comments on every
| article, you'll see patterns that are not reflections of
| a single position held by any particular person. If you
| see contradictions in things that I've written, I'd love
| to have them pointed out, but saying that "one set of
| people on HN say X and another set of people on HN say !X
| or X'" just doesn't really convey anything that seems
| actionable or even that interesting. "People have
| different opinions! News at 11!!"
|
| 2) After I posted the comment you're replying to, I was
| absolutely certain that the question of which level of
| control was appropriate would come up (since that's
| really what we're discussing in the context of git). It
| doesn't seem obvious to try to carry the analogy too far,
| but for both systems there are obviously different levels
| that one can think about. I haven't used a CNC system,
| but I would imagine that there are _very_ high level
| control systems that maybe start from some sort of design
| data and take it from there, some mid-level control
| systems that let you specify what you need and then
| program the machine to create it, and low-level control
| that would be rarely used unless the higher level tools
| just couldn 't do what was needed.
|
| If indeed this is an accurate description, then it seems
| to match the case with git quite well, and I'd still
| argue that even if you often/sometimes use the very high
| level control tool, you should understand and be aware of
| the possibilities of the lower level ones too.
| PragmaticPulp wrote:
| > 1) I don't think it ever makes much sense to have a
| concept such as "HN is really strange on ...".
|
| I enjoy HN, but I've also been here long enough to accept
| that HN is an echo chamber. Yes, we have downvotes and a
| variety of opinions, but the reality is that if you come
| into certain threads expressing certain unpopular
| opinions you're going to get hit with a wave of
| downvotes. Eventually you learn to just stop posting
| those opinions, which results in an echo chamber effect.
|
| No social media site is free of echo chamber effects. HN
| is not an exception.
|
| > I haven't used a CNC system, but...
|
| Friendly suggestion: If you're not familiar with how
| something works, maybe it's not the best subject for an
| analogy?
| PaulDavisThe1st wrote:
| "Haven't used" isn't the same as "have never been in a
| shop with a CNC system installed, never worked around
| people using them, and have no close friends who use them
| regularly".
|
| As for the echo chamber, you won't be suprised that I
| disagree with you on this point.
| u801e wrote:
| > 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.
| benglish11 wrote:
| 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.
| aetherspawn wrote:
| I prefer to rebase on the terminal also, but I reference
| Sourcetree when doing it.
| emsy wrote:
| 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.
| gallier2 wrote:
| 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.
| baq wrote:
| Wow, I'd never call version control simple. Actually it's
| fiendishly hard. Git makes some simplifications (!) to make
| the problem more tractable.
| mikeyjk wrote:
| What VCS system is simpler? I've used mercurial, svn and git,
| and git seems the far easier of that sample space.
| akamoonknight wrote:
| 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.
| jamesmontalvo3 wrote:
| 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
| jbverschoor wrote:
| I'd rather use a "visual tool" to visualize
| akamoonknight wrote:
| And that's totally valid. gitk is my main experience with
| visual git tools and using it gives a ton of information
| that is not only visually nice to look at, but also
| pretty easy to navigate. But gitk isn't always the most
| available and sometimes I just need a quick look at the
| history. They're all just tools in the toolbox, but even
| knowing the tool exists is a first step.
| 90minuteAPI wrote:
| No apparently that means you don't know what you're
| doing, and you'll corrupt the repo, and you're not a real
| software developer so we'll come to your desk and rip up
| your I'm A Very Serious Professional card.
| jbverschoor wrote:
| It's funny, because most devs that are pro CLI for these
| kind of things, are actually unable to operate vi, or
| install any server / container without installing a
| complete desktop environment.
|
| Let's all go back to the ed line editor
| res0nat0r wrote:
| 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.
| gallier2 wrote:
| 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.
| azundo wrote:
| While reflog is amazing, the "ever" in your statement is
| not true, `git gc` will prune your reflog: https://git-
| scm.com/docs/git-gc
|
| Most of the time this doesn't matter in practice but you
| should be aware that unreachable refs don't stay around
| forever.
| alerighi wrote:
| 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.
| snarfy wrote:
| 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.
| eloisant wrote:
| 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.
| sharken wrote:
| As someone about to migrate from Mercurial to Git i
| absolutely agree that Git is the superior tool.
|
| Pull Requests were never going to happen with Mercurial and
| it's also not possible to delete a branch without some
| black magic server-side.
|
| And with Git hopefully it will be possible to move to
| Trunk-based development, although that requires a lot more
| than just switching to Git.
| rbreaves wrote:
| 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.
| ThrowawayR2 wrote:
| Isn't that the "appeal to authority" fallacy? Mercurial
| demonstrates that you can have a VCS with less painful and
| frequent gotchas and certainly the grottiness of the git
| submodule mechanics, for example, doesn't show as much
| thought and care as one would hope.
| pofjer wrote:
| How does Mercurial show it? I always found it very
| confusing to use all the times I tried it so I would need
| some context to understand your comment.
| wpietri wrote:
| If "the issue at hand" is running a globe-spanning open-
| source project with hundreds of contributors, a bunch of
| targets, and a code base that goes back 30 years, sure, I'm
| happy to listen to Torvalds.
|
| if "the issue at hand" is the more typical modern work
| environment for devleopers, then no, I don't think he has
| much special insight. Indeed, the fact that he's wrangling
| something so large and important means he's unlikely to
| have the time and attention to devote a lot of thought to
| how best to serve a pretty different group of people.
|
| An obvious consequence of this is git's terrible interface.
| Its premise is "if you totally understand what Git is up to
| under the hood, the interface is great!" Fine for a small
| in-group of kernel developers whose lives are distributed
| patch sets, but terrible for the average developer. It has
| taken 15 years to get some reasonably named commands for
| common things like "restore a file". That's a great sign
| that we shouldn't listen to Torvalds on topics outside the
| realm of his admittedly impressive expertise.
| geofft wrote:
| This isn't about "understanding the issue at hand," this is
| about UX development.
|
| Linux is, very intentionally, a piece of software which
| does not have "easy to understand for non-experts" in its
| design goals. You generally interface through Linux with
| system call wrappers provided by a libc (or another
| specialist library for other interfaces like libfuse or
| libnetfilter or whatever), not directly. Linus is, quite
| obviously, good at many things; it's silly to assume that
| means he's an expert at everything.
|
| Linus developed Git as a low-level tool. Linus put a lot of
| thought and care into getting the implementation details
| right, but _intentionally_ did not build an easy-to-use
| interface. The Git command line that people use today
| ultimately derives from Cogito, a toolkit written by
| someone not Linus that sat on top of Git. Eventually Git
| (which Linus had long since handed off to someone else)
| adopted most of the conventions of Cogito and created a
| "porcelain"/"plumbing" split. If you think it was arrogant
| to develop Cogito, I suspect you disagree with Linus.
|
| Finally, Linus develops Linux with a very particular model,
| with e-mail-based patch reviews, merges from subsystem
| maintainers, etc. Most projects (even most open-source
| projects, but certainly almost all proprietary projects) do
| not work this way. The Linux kernel does not use a GitHub-
| style workflow for development, which is by far the most
| common way people outside the kernel community use Git. It
| may well be the case that a lot of thought was put into
| making Git work really well _for Linus 's use case_ but it
| does not match how other people do development.
| PaulDavisThe1st wrote:
| The difference between the kernel development model, and
| some putative "typical other" development model merely
| changes which git commands/tools get used to handle
| getting stuff into a particular branch on the canonical
| repo.
|
| It has no impact on the underlying concepts that make git
| scale well, cover 100% and 100% remote cases equally
| well, and provide deep under-the-hood concepts that can
| be deployed in exceptional circumstances.
| geofft wrote:
| Correct, it has no impact on the _internals_ of Git,
| which was my point. Git 's internals are used by both the
| kernel development workflow and the GitHub-style
| workflow, and Linus designed it well.
|
| The conversation is about the _user experience_ of using
| Git - its CLI design, etc. It is entirely about "merely"
| what commands are being used. TFA is about new Git
| commands, not about any changed internals. Or, in the
| case of Sourcetree, it's about not using any of "Linus's"
| interface to Git (which, again, wasn't written by Linus)
| but interacting with the same Git internals.
| PaulDavisThe1st wrote:
| I think the conversation is about whether or not the
| Sourcetree interface to git can be useful when carrying
| out tasks that involve, for example, filtering the
| reflog.
|
| If you have never done this before, and have only ever
| used git via the ST interface, switching to the CLI to
| get this done is going to be quite a shock. Maybe that's
| OK because realistically such tasks should be rare. But
| sometimes they are a critical task in development, and
| finding that the entire dev team is completely
| intimidated by it can be an issue.
| cerved wrote:
| we use it because it's blazing fast, stable and extremely
| versatile
| jen20 wrote:
| I'd add another reason to that: we're using Git because
| BitKeeper wasn't free (as in beer) at the time for general
| purpose use. Had it been, we'd all be using BitKeeper
| instead.
| mberning wrote:
| It's not very fast when you account for all the time and
| productivity wasted on getting "unstuck" all the time.
| cerved wrote:
| I devoted some time to RTFM and actually learning how
| things work so I can't say that I run into this issue
| reidjs wrote:
| Once you get over the initial learning curve you will not
| get stuck very often
| alerighi wrote:
| 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.
| oauea wrote:
| 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 wrote:
| 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.
| Nursie wrote:
| How are version control systems _meant_ to be used, if not
| as a history of the work? If not as a remote backup of work
| in progress?
|
| I _get_ the whole "we should have a neat history of feature
| commits" argument, but that's really only one facet of a
| good source control system.
|
| The fact that these goals appear to conflict shows me
| there's some sort of lack in git. For all its (many, many)
| problems, uber-complex source control system ClearCase at
| least allowed you to specify a view, so you could see both
| types of information depending on your use-case.
| jen20 wrote:
| They're not really in conflict at all. The workflow I've
| been using for ~11 years is:
|
| - Make a branch for my work.
|
| - Commit early, often and with often meaningless commit
| messages like "WIP" or "try x" or "nope x doesn't work,
| do y instead" - in other words, what the work was.
|
| - Push this branch to a remote (either personal or shared
| depending on policy) largely to synchronise between
| machines, but also as a backup.
|
| - When ready to integrate, interactively rebase into a
| set of cohesive units which are independently buildable
| and have detailed commit messages which explain why the
| work was done, not what the works was.
|
| - Push _this_ as a pull request, Gerrit change set, or
| email patch, depending on policy.
|
| This approach gives you the best of both worlds: fast,
| easy backup and easy unwind when doing work, and a clean
| history for the benefit of future developers on the
| project.
| Nursie wrote:
| You still lose your real commit history though, and I've
| found it useful to have that in the past. A dead end or
| experimental avenue that turned out not to have use at
| the time turns out to be a real timesaver later.
|
| I'm fact I've found that far more useful than a well
| curated history.
|
| Having both would be a good thing. Having both in a not-
| ridiculously overcomplex system even better... I wonder
| if there even is a sweet spot.
| jen20 wrote:
| I agree that having both would be preferable - and to
| some extent GitHub gives you that (via the "squash and
| merge" button). Unfortunately it doesn't appear that
| workflow is usable in a lot of cases since the commit
| message cannot be reviewed independently in this model,
| unlike in Gerrit.
|
| You can always keep your working branches on a personal
| remote, or interesting sets of changes in gists, however.
| quietbritishjim wrote:
| > 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!)
| conradfr wrote:
| I learned git with the CLI. Occasionally I will use it.
|
| But I see no reason to not use Jetbrains beautiful
| beautiful git integration for almost everything. It really
| is just ... perfect.
|
| But if people want to feel superior by typing commands in a
| terminal, go ahead.
| SOLAR_FIELDS wrote:
| My experience also supports this. I think resolving
| complicated merge conflicts is the best argument for using
| an IDE with Git. My experience of having to maintain a fork
| of a code base where there was frequently a lot of
| conflicts showed that I would reach for IntelliJ to resolve
| complicated conflicts even if it wasn't Java files. The 3
| window visualization they use is just great for seeing
| conflicts in large files that span hundreds of lines of
| code.
|
| I use the terminal commands for everything else though.
| Lio wrote:
| I would say that depends on your background.
|
| This is just me but I'm quite happy viewing the graph via
| CLI and doing interactive rebases to fix issues.
|
| I have no problems with other people preferring a GUI but
| all I've tried have been confusing for me.
| chipotle_coyote wrote:
| > 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.
|
| This is an argument for a good GUI _diff /merge tool,_
| which is not necessarily the same thing as an argument for
| a GUI Git client; I think the two uses are being conflated
| a lot throughout this comment thread. I have Kaleidoscope
| set as my default mergetool and difftool, but I'm still
| working with the git CLI nearly all the time. (I use Gitup
| on the occasions I want to stage changes to individual sets
| of lines in the same file as multiple commits, and
| exceedingly rarely if I'm trying to do something
| frightening with a local as-yet-unshared feature branch.
| There are times being able to undo with Cmd-Z is really
| helpful.)
| quietbritishjim wrote:
| You're right that there are two different parts to a
| these, but I think they both benefit from graphical
| tools.
|
| I'm talking about a VCS tool telling me that the rebase
| had got to commit n of m and a conflict has been
| encountered, and which files have conflicts resolved
| (either automatically or I've manually resolved then so
| far in this tool), and which other files have conflicts
| outstanding. Then I can invoke the three way merge tool
| from there (which is indeed hugely better than a command
| line tool). Something like this (except this is for Hg):
|
| https://i.stack.imgur.com/kaFNz.png
| lobocinza wrote:
| Vim has some plugins that make it a lot easier/quicker.
| User23 wrote:
| Magit[1] is also excellent. And like all good git tools it
| exposes a log of what it did. Unfortunately it doesn't work
| so great with megarepos, but I understand that's being
| worked on. One area where this tooling is vastly superior
| to the command line is adding hunks instead of files to a
| commit, making it much easier to have a sensible history
| while allowing programming in a more natural style.
|
| [1] https://magit.vc/
| poidos wrote:
| +100 for Magit. My favorite feature is rebasing directly
| on logs.
| Shorel wrote:
| I use Meld in case there are conflicts of these types. The
| CLI can be configured for that, and mine is set up that
| way.
|
| But truly, I never just use plain pull, but pull --rebase,
| and I have not experienced such a conflict in years.
|
| The commit history also stays a bit more linear. (Other
| developers use normal pull).
| cerved wrote:
| A combination of git diff, git checkout --ours/theirs . &&
| git add and git mergetool works well in my experience
| pkulak wrote:
| Sublime Merge's three-way merge is so good. It's totally
| spoiled me.
| he0001 wrote:
| Is sublime doing the merge instead of git? Or are you
| referring to use sublime as the merge tool to resolve
| conflicts?
| pkulak wrote:
| Just for resolving conflicts.
| joombaga wrote:
| Sublime Merge is a GUI git/mergetool, from the makers of
| Sublime Text.
| filoeleven wrote:
| SourceTree doesn't give up. It tells you that you have
| conflicts to resolve. Once you do, "continue rebase" does
| what it says, either until the rebase completes or until it
| hits another conflict.
| quietbritishjim wrote:
| Does it show a GUI, analogous to [1], or tell me to sort
| it out myself on the command line? I'd it's the latter
| then that's very much giving up. On the other hand, it's
| possible I'm mixing it up with some other GUI I tried.
| gallier2 wrote:
| The only visual git tool I really like is gitextensions for
| windows.
| V-2 wrote:
| Fork has its advantages too (and a slicker UI if that
| matters for you)
| intellix wrote:
| 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
| detinho wrote:
| 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.
| larusso wrote:
| 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.
| z3ncyberpunk wrote:
| So what you're saying is that you're 10 years of experience
| were you solely to over specialize in a single application
| utility which ultimately adds up to an absolutely giant pile
| of inflexibility and incompetence?
| zwischenzug wrote:
| 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.
| voakbasda wrote:
| Any developer demonstrating that level of daily
| incompetence with their basic tools of the trade should
| never be allowed to write code. The fact that this level of
| incompetence seems the rule rather than the exception
| speaks to the rather terrifyingly pathetic state of
| software, where badly engineered systems end up killing
| people. Source: firmware engineering consultant that cleans
| up messes like these for some of the biggest corporations
| in the world, who build things that will kill people when
| they fail. I would love to blow the whistle, if I thought
| that would have any positive outcome whatsoever.
| jjnoakes wrote:
| In my opinion this is way too much gate keeping.
|
| 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.
| alisonkisk wrote:
| The point is that we care about the quality of the
| software at all times, not elegant graphs of its history.
| jhayward wrote:
| Oh, boy, do you _really_ want to say that? I have some
| questions about numerical algorithms that you probably
| rely on every day for you.
| politician wrote:
| We ask candidates the most ridiculous algorithm and data
| structure design questions when we should be asking them
| to describe the git data structures. Let's fix interviews
| and kill two birds with one stone.
| saagarjha wrote:
| Git is mostly one (clever) data structure.
| BlueTemplar wrote:
| Huh, how did it get _so_ bad that "blow[ing] the
| whistle" about "things that will kill people when they
| fail" "would have [no] positive outcome whatsoever" ?!
| galangalalgol wrote:
| I'll admit as a 20yr c++ developer, I don't know what
| rebase is or when to use it. I've only been using git for
| a few years, cvs before that. I commit and push often,
| then do a merge request via a web portal gui(bitbucket or
| gitlab), then merge it squashing commits again using the
| gui.
| jbluepolarbear wrote:
| I prefer merge/fast forward because I want all history
| preserved. People can rebase their changes in their
| branch, but rebasing is never done on the main or
| development branches. Most of the worst merge conflict
| I've had to deal with were caused by someone rebasing
| changes they didn't make. I reject all pull requests that
| change history.
| smt88 wrote:
| 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.
| oli-g wrote:
| 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.
| dagw wrote:
| 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"
| Shywim wrote:
| > Most Git GUIs map fairly closely to the underlying git
| model.
|
| 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.
| zkldi wrote:
| You can see the original error message in vscode by
| clicking "output" and navigating to Git in the dropdown.
| FunnyLookinHat wrote:
| 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. ;)
| gavinray wrote:
| Eh, that term seems to have fallen out of favor compared to
| when I was a growing up but I don't think it necessarily
| has a negative connotation.
|
| 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
| ketzu wrote:
| My personal experience around noob is covered by the ones
| I found on ~~most~~ edit: the most high search-ranked
| online explanations: Mostly negatively conotated,
| deregatory version of newbie. Often associated with
| people not sufficiently able to learn or at least not
| learning on their own.
|
| 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.
| cratermoon wrote:
| I've been around long enough and in enough circles that I
| have seen 'noob' go from mildly chiding to full-on
| insult. It used to be that in some communities, being
| referred to as a noob was a sort of "hey check out the
| new guy" ribbing. A noob was just someone starting out, a
| neophyte. It was the impatient and rude who later decided
| that being a noob was a bad thing.
| b3morales wrote:
| I often see people self-describe as noobs when asking
| technical questions, for example in programming Reddits.
| I couldn't say that I understand the reason for it,
| though.
| edoceo wrote:
| Noob is the first step to being a master. So, those
| "noob"s are indicating they're early in the process.
| derac wrote:
| Saying you're a novice when asking for help can be
| useful. People will use less jargon and point to more
| accessible resources, etc.
| IgorPartola wrote:
| "Hey can you help me? I stood up a kratr pod and it's lined
| to fundle but for some reason when I try to press the bin
| tree to the overlay layer the reznik instance on my laptop
| says 'out of tokens'. Have you ever encountered this?" No,
| no I have not.
| dagw wrote:
| Having been troubleshooting computers since I was
| literally 8 years old (like I'm sure many of us here
| have) I feel reasonably comfortable I could at least be
| helpful solving this problem as well.
|
| Every problem I have to troubleshoot is almost by
| definition one I've never encountered before.
| IgorPartola wrote:
| I can help. It doesn't mean I've encountered it before.
| nuclearnice1 wrote:
| 100% Great attitude. I'll meet you where you are and help
| out.
| CrazyPyroLinux wrote:
| Yup - Every darn time. Reminds me of "How it feels to
| learn JavaScript in 2016"
| https://news.ycombinator.com/item?id=12628921
| jbluepolarbear wrote:
| 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.
| thwarted wrote:
| But are you an expert in the IDE? Are they having a problem
| with git or are they having a problem with the IDE?
| jbluepolarbear wrote:
| It's usually a mix of both ide and git issues. And yes
| I've become an expert in using Sourcetree and GitHub
| desktop. I actually like GitHub Desktop a lot and use it
| for most dev now.
| Dayshine wrote:
| Every IDE I know shows you a log of the raw commands its
| running. I use the IDE first, then if something goes
| wrong (which very very rarely happens, git isn't exactly
| complicated) I check the log and see what it's trying to
| do.
| MarkSweep wrote:
| 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.
| einherjae wrote:
| git add -p
| MarkSweep wrote:
| Oh thanks, that works fairly well. I still prefer git-gui
| for this, but this will work nicely when I'm ssh-ed into
| a machine with no GUI.
| dmz73 wrote:
| 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.
| agilob wrote:
| 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!
| nicoburns wrote:
| Sublime merge would have been a good suggestion in this
| scenario. It's UI uses standard git terminology and
| concepts, so you'd have been sneakily trainig them in the
| command line whilst they used the UI!
| agilob wrote:
| It was in a very old fashion and regulated working
| environment where developers and testers aren't allowed
| to install whatever they want. Software installers can be
| whitelisted after a review is done. It included things
| like: licence OSS vs enterprise, support, community, or
| even more banal things like stars on github. Adding new
| software to a list could take literally months - like in
| case of git GUI client. Sublime was frequently requested
| but managers were responding "you already can install
| Eclipse and Intellij, you also have Notepad++, you don't
| need more editors. More editors installed is a security
| risk to this company!" (some hackers found a way to run
| VSCode portable edition which didn't offer updates ;))
| This was end of discussion.
|
| 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.
| DangitBobby wrote:
| The git GUI in Intellij and related products is really
| quite good. The diff view that shows three adjacent panes
| for conflict resolution (|theirs ->|merge|<-yours|) is so
| much better than the normal conflict resolution flow (not
| least because you still get the normal code highlighting
| in it), and separate checkboxes for each changed section
| of the diff makes it so easy to chunk large changes into
| logical commits. I wish they offered it as a standalone
| product.
| LambdaComplex wrote:
| What was their justification for being like that?
|
| Sometimes I read these things and end up saying to myself
| "Wow, that company just literally hates being productive"
| agilob wrote:
| >What was their justification for being like that?
|
| 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.
| nicoburns wrote:
| Not necessarily. On my team at work we have people using
| Sublime Text, VS Code and vim, but all 3 (+ our CI) plug
| into ESLint and TypeScript for ensuring style coherence.
| tsimionescu wrote:
| You should have recommended Emacs Magit just to see the
| looks on everyone's faces.
| agilob wrote:
| Funny enough, one argument against cli git was 'vim' as
| commit text editor ;) Maybe emacs would convince them!
| lorenzhs wrote:
| Did changing GIT_EDITOR to something else not cross their
| minds? Or did they not even bother to check if it can be
| changed?
| spkm wrote:
| 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.
| crazygringo wrote:
| 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.
| samatman wrote:
| Just as a data point, I unselfconsciously describe myself
| as a noob (or more likely n00b) when I'm inexperienced with
| something, and still prone to making embarrassing mistakes
| because I don't know what I'm doing.
| laumars wrote:
| I get you disagree with the GPs post but "noob" isn't
| offensive. What's offensive is their lack of support for
| colleagues (which reads like a potential issue with their
| own ego: where they didnt want to be shown up in an
| unfamiliar UI). But their post reads exactly the same if
| you substituted "noob" for "newbie", "junior",
| "inexperience" etc.
|
| 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.
| tehbeard wrote:
| > which reads like a potential issue with their own ego:
| where they didn't want to be shown up in an unfamiliar UI
| > What there should be is shame ... those who don't offer
| up their help to others
|
| I read it more as, I don't want to be become L1 Tech
| Support for something I don't know either.
| laumars wrote:
| What happens when the GP runs into an issue themselves.
| Do their colleagues help him or return the same cold
| shoulder?
|
| Computers are sufficiently advanced that there will
| always be blind spots in your team. Sometimes that means
| working together as a team to figure them out. Which is
| the kind of behaviour a good manager should encourage and
| the sort of attitude a good senior engineer should have
| already learned.
| hedora wrote:
| I don't think they meant noob as a pejorative.
|
| 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).
| crazygringo wrote:
| > _Optimizing everything around developers that can't
| figure out the CLI sounds like a great way to attract
| bozos_
|
| 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.
| [deleted]
| indymike wrote:
| > 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.
|
| Unfortunately, a word needs to exist that stands in for
| this:
|
| "Person, who isn't so different than myself when I started,
| with little experience who is mistake prone due to the lack
| of experience, who's mistakes creates disruption and often
| great expense at the most inconvenient times."
|
| Being offended by noob just makes communication more
| difficult, and does not really change anything. We've had
| all kinds of much more offensive names for the same thing
| (many other names imply race, social status and so on).
| noob seems to be about as offensive as rookie, but one
| syllable less.
| alisonkisk wrote:
| Newbie is a nicer word.
| cain wrote:
| Noob is just a contraction of Newbie. Newbie -> Newb ->
| Noob. It's still used interchangeably with Newb.
| b3morales wrote:
| Why?
| kangalioo wrote:
| "Noob" has a negative connotation.
|
| https://www.urbandictionary.com/define.php?term=Noob
|
| > Contrary to the belief of many, a noob/n00b and a
| newbie/newb are not the same thing. Newbs are those who
| are new to some task* and are very beginner at it,
| possibly a little overconfident about it, but they are
| willing to learn and fix their errors to move out of that
| stage. n00bs, on the other hand, know little and have no
| will to learn any more. They expect people to do the work
| for them and then expect to get praised about it
|
| The specifics of the definition probably vary depending
| on who you ask but that's roughly it.
| crazygringo wrote:
| Indeed, and it should be clear that "noob" is
| intentionally/cleverly spelled like "boob" in the sense
| of "idiot". That's the _whole point_ of the word -- that
| 's the joke.
|
| Now it's fine to joke around and call _yourself_ a noob,
| that 's just self-deprecating.
|
| But if you're talking about other people and don't want
| to inadvertently offend, stick to "newbie" in speech or
| "newbie/newb" in writing, which have a connotation
| entirely of "beginner" as opposed to "idiot".
|
| (Of course, if you're among friends where you enjoy
| making fun of each other, say whatever you want!)
| bavell wrote:
| I agree with your last paragraph but "noob" is offensive?
| That's just silly... it's like you said, we've all been
| there once and it's a useful term for quickly describing
| where one's at. There's no inherent malice unless
| intentionally added by the speaker/poster.
| cannabis_sam wrote:
| 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..
| BlueTemplar wrote:
| Yeah, hence see the criticisms of git from completely
| different sides from fossil devs on one hand and pijul
| dev(s?) on the other.
|
| Git probably has its place, but only on very specific,
| large scale projects, with a crack core team and hundreds
| of drive-by contributors ?
| tehbeard wrote:
| > Git probably has its place, but only on very specific,
| large scale projects, with a crack core team and hundreds
| of drive-by contributors ?
|
| So, hypothetically, if that were the case, what is the
| recommendation for Small/Medium web agencies?
| Dudeman112 wrote:
| No versioning at all, of course.
|
| 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.
| a-dub wrote:
| > 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?
|
| 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.
| 0xEFF wrote:
| 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.
| mattrighetti wrote:
| Using git from cli is like driving a Ferrari in a road with
| 30km/h speed limit
| mberning wrote:
| 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.
| bob1029 wrote:
| > 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.
| jupp0r wrote:
| 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.
| tryingtogetback wrote:
| 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 wrote:
| It's more like getting the dental assistant to operate the
| autoclave.
| tryingtogetback wrote:
| Endless opportunity for analogies here. The gist is that
| you are delegating all sensitive versioning and versioning
| history management operations to a 3rd party with extremely
| limited capabilities, 3rd party you know nothing about
| (effectively a black box).
|
| We thrive on abstractions, but unfortunately in case with
| versioning and git in particularly, GUI apps is a wrong
| one.
| aniforprez wrote:
| Your analogy is completely awful
|
| The janitor knows nothing about dentistry. The git GUI
| knows plenty about it and the devs make it their job to
| know it too. A janitor is not an abstraction, he's a
| liability. If a GUI abstraction helps me get the job done
| faster, I really don't see the problem. Plus almost every
| one of them fully state the commands being used to
| perform every action and have logs you can parse. I used
| to use Sublime Merge and now use Fork and both have this
| tryingtogetback wrote:
| You are contradicting yourself and making my point for
| me.
|
| janitor is an abstraction (you trust a janitor to operate
| with a professional tool for you) and you are completely
| right, git GUIs (just like a janitor) are a liability.
| aetherspawn wrote:
| If your janitor makes the client happy maybe he should
| retrain as a dentist?
| Shorel wrote:
| 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.
| emodendroket wrote:
| I find the visual ones often harder to use but that's just me.
| Whatever works works.
| MisterBastahrd wrote:
| Wonder how many command line enthusiasts are using gitflow to
| make things even simpler than sourcetree.
| neop1x wrote:
| >> 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 wrote:
| 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.
| madeofpalk wrote:
| 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".
| nerfbatplz wrote:
| 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.
| adwww wrote:
| I seem to use cherry-pick at least monthly, as well as log
| and diff.
| paulddraper wrote:
| 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.
| agilob wrote:
| 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).
| magoon wrote:
| Commands are explicit and shareable. If you've mastered <ide>
| then good on you, but it makes you an island.
| smusamashah wrote:
| 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.
| gumby wrote:
| 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 wrote:
| 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/ )
| stormbrew wrote:
| 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.
| crummy wrote:
| I don't understand how "using a GUI to drive this tool"
| instead of "using a CLI to drive this tool" means someone
| doesn't understand version control, doesn't care about how
| their code interacts with their team, or doesn't know how
| the tool works.
| stormbrew wrote:
| I don't understand how I'm supposed to reply to this
| given that it claims I said something I didn't even come
| close to saying and has nothing to do with what either me
| or the GP post were replying to.
|
| If you want to try again, the central thesis of my post
| was:
|
| "Using git (or some kind of version control) is, in fact,
| your job."
|
| With a digression that amounts to:
|
| "The disdain OP's post shows towards people who take the
| time to understand the tools fundamental to performing
| their job is extremely unappealing to me in a coworker"
| (ie. the "they should get a job managing a git repo or
| something" part)
| crazygringo wrote:
| 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 wrote:
| 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.
| themulticaster wrote:
| Just in case you didn't know, there is git add -p (or
| --patch) which does precisely what you want: It splits your
| changes into small parts ("hunks") and allows you to
| specify whether to stage every hunk. I don't know your
| exact workflow in Sourcetree, but most likely git add -p is
| the CLI equivalent of the Sourcetree interaction you
| describe.
|
| Bonus commands: -p/--patch also works for git stash
| (allowing you to stash only certain changes) and for git
| checkout (allowing you to discard only certain changes).
| Since I'm an Old School Git user I actually don't really
| know the restore/switch commands, but apparently git
| restore supports -p/--patch as well.
|
| Another neat git add flag is -u/--update: The manpage is a
| little confusing on this flag, but essentially it makes git
| add ignore untracked files (it will only stage files that
| are already part of the repository). If you're like me, you
| have tons of files laying around in the project folder
| (e.g. benchmark results or local test input files) that you
| don't want to commit and yet don't want to add to the
| .gitignore file (since the files are really just temporary
| files, other users have no use for the gitignore entries).
| By using git add -u, you prevent adding them by mistake in
| a command like git add src/ and realizing a few weeks later
| that you accidentally added 10 MB of cat pictures to a
| bugfix commit. If you can identify with this story then git
| add -u is made for you.
|
| Another bonus fact: If the temporary testing files
| mentioned in the last paragraph ever reach the status of
| permanent testing files, and they're still only useful to
| you personally (so adding them to gitignore doesn't make
| sense), Git has a little-known feature: You can add local
| ignore patterns (same syntax as gitignore) to
| .git/info/exclude (go ahead and check, this file most
| likely already exists in your Git repository). These
| patterns are not be part of the repository itself (you
| don't commit them), rather they act as local configuration.
| The idea is that you put exclude patterns that are valid
| for _every_ user of the project (e.g. target / for a Rust
| project) in .gitignore, and _local_ exclude patterns for
| your IDE /editor configuration (.vscode/, .idea/ and
| friends) and similar files in .git/info/exclude.
|
| In conclusion, I only every run a) git add -u $file (when I
| want to add all changes made to an _existing_ file), b) git
| add -p $file (when I want to add only certain changes made
| to an _existing_ file), or c) git add $new_file (when I
| consciously want to add a _previously untracked_ file).
|
| These three commands are all you need if you're in the camp
| of Git users that at least try to make every commit a good
| package (single, reasonably-scoped and atomic change). If
| you're in the git commit -a/"squash all intermediate
| commits into one single monstrous commit" camp then.. have
| fun with your cat pictures, I guess.
|
| I hope that was at least a little bit helpful to someone.
|
| May I ask why you drop into VS Code for interactive
| rebasing? Is it about resolving the merge conflicts, or
| editing the rebase command list? I'm just going to drop two
| more nice Git features here, but I'll stop myself now
| before I write too much: git commit --fixup= together with
| git rebase --autosquash, and git rerere (not a typo).
| einherjae wrote:
| I'm in the same camp, often staging is easier to handle
| with a GUI, particularly if you want a partial staging.
|
| But then again, there is always git add -p
| Karsteski wrote:
| Good article. I've been using git switch since I started using
| git CLI a few months ago, but restore is new to me!
| tkfu wrote:
| 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 wrote:
| 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 wrote:
| Except this is actually the opposite... they turned one command
| that did too many things into two commands which each do fewer
| things.
| nine_k wrote:
| 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 wrote:
| 'switch' to these commands, hehe
| layoutIfNeeded wrote:
| No thanks, I will keep using checkout.
| leephillips wrote:
| 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?
| layoutIfNeeded wrote:
| 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.
| philote wrote:
| 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 wrote:
| 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.
| levzettelin wrote:
| 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"
| cush wrote:
| > properly
|
| Or maybe just don't shame people for not working the way you
| do.
| mtekman wrote:
| In a similar manner for Emacs users: magit-toggle-refine-hunk
| is a lifesaver for word diffs
| andreareina wrote:
| Key combo `D t`
| NilsIRL wrote:
| I also like to use `git diff --color-words=.` to do a character
| wise diff instead.
| leephillips wrote:
| Thanks for teaching me about --color-words. I didn't know about
| it, and I greatly prefer it over the normal git diff output.
| lisper wrote:
| > 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
| richrichardsson wrote:
| > What's the alternative
|
| Perfectly explained here : https://xkcd.com/1597/
| ozim wrote:
| 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.
| krainboltgreene wrote:
| > By "properly" - I mean not messing up your own or others
| work in unpredictable ways.
|
| The parent's point still stands: No one is out there
| choosing to use git in "unpredictable" ways.
| ozim wrote:
| No, if you have modicum of abstract thinking and spend up
| to 30 mins daily using GIT you don't use git in
| "unpredictable ways".
|
| If someone is a software developer, for me basic
| requirement is having possibility to understand this.
| Shacklz wrote:
| > 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.
| lisper wrote:
| See my earlier comment here:
|
| https://news.ycombinator.com/item?id=27580478
| Shacklz wrote:
| Regarding your first point (and I think some of the
| commenters in that thread also address this already) is
| that as long you don't have uncommitted changes, you're
| safe. You're right that a lot of git-commands mess with
| uncommitted changes in hard-to-recoverable ways, but once
| changes are committed, there's almost no way to mess
| anything up, you can always go back to the previous state
| (git reflog <branch> telling you which commit that was).
|
| Regarding the second point - if you have a rebase-based
| work-flow, you will encounter this problem less often (or
| not at all).
|
| For your third point - what helped me a lot is to
| actively distinguish between commits and the working
| tree, and making myself aware that branches really are
| just "pointers" to commits (obviously, but somehow,
| actively thinking about it made the intent of git
| commands a lot easier to understand). Also, most git
| commands are just combinations of other commands. git
| reset is just moving the pointer (--soft without touching
| the working tree, --hard will do so), rebase is
| essentially a hard-reset with consecutive cherry-picks
| afterwards, and so on.
|
| Also, an eye opener for me personally has been that e.g.
| an interactive rebase with squash towards a branch that
| is strictly ahead of you except for the commits you want
| to rebase is essentially just a "git reset --soft
| <target>", and then recommitting everything with a fancy
| commit-message. This and similar mental gymnastics with
| git-commands has helped me a lot; most of them really are
| quite sane (except for all those crazy options), "git
| checkout" is really the odd-one-out of the bunch (and
| "git pull" a combination of things that should never have
| been combined in the first place).
| lisper wrote:
| Yeah. That clarified everything.
| plorkyeran wrote:
| 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.
| yjftsjthsd-h wrote:
| > 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".
| TameAntelope wrote:
| A viable alternative my coworkers seem to have adopted is,
| "Execute the git commands blindly as provided by me and get
| upset with git when something doesn't work right."
| lisper wrote:
| See my earlier comment here:
|
| https://news.ycombinator.com/item?id=27580478
| imiric wrote:
| 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 wrote:
| 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
| adrianmsmith wrote:
| 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.
| rubyn00bie wrote:
| I'm surprised no reference to:
|
| git switch -
|
| For going back to the previous branch you checked out.
| hsn915 wrote:
| This is not new. It works the same with the checkout command.
| git checkout -
| akx wrote:
| 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?
| erik_seaberg wrote:
| 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.
| jonwinstanley wrote:
| The author did say that had only recently discovered these
| commands. Unsure why they said they were new, maybe they were
| kidding?
___________________________________________________________________
(page generated 2021-08-01 23:00 UTC)