20 ms·

Damn, this is such a GREAT idea. I've messed up repos a few times, and it's never good. It's always -- "what's the magic want I have to wave now"? The truth is

Damn, this is such a GREAT idea. I've messed up repos a few times, and it's never good. It's always -- "what's the magic want I have to wave now"? The truth is, while we use git every day, most people really don't understand how it works. There I said it. And I'm not ashamed. I don't really know how Git works. And I think I'm not the only one. What does "git reflog" or "git reset --hard ...." do? What are the implications? We don't really know. I feel stupid. But hey, at least I'm honest.

sebmellen 5y ago
For some reason people love to defend the obscure and strange and oftentimes objectively terrible Git CLI. I’ve found Mercurial much more straightforward for my (mundane and boring but prevalent) use cases, and I lament that it isn’t more widely used.
- zibzab 5y ago
  Every single time we are discussing git this comment shows up. But why is one popular when the other one is so much better? I guess we will never know
  - disgruntledphd2 5y ago
    GitHub is the reason. Turns out giving beer to developers globally is an effective way to get a technology adopted.
    - zabzonk 5y ago
      Bitbucket used to provide free (and pretty good) Mercurial hosting.
      - oblio 5y ago
        Bitbucket had a much crappier UI.
        zabzonk 5y ago
        Actually, one of the reasons I preferred hg to git is that Windows explorer GUI integration back then was far superior to gits, which was buggy as hell.
        ivanbakel 5y ago
        This doesn't seem relevant to the comment you're replying to. Bitbucket's web UI sucks, which is why it didn't have the effect on Mercurial that Github had on git. Having used Bitbucket and GitHub, I think GH is much nicer - both in the sense of basic stuff like page loads being faster, and in terms of features. And since it's the main tool that everyone on the development team spends their time on for communication & collaboration, those things really matter.
        mixmastamyk 5y ago
        Also, remember to compare the sites ten years ago rather than today.
  - zabzonk 5y ago
    The Torvalds effect.
    - zibzab 5y ago
      I know you imply, but this could also be interpreted as "battle proven" or how about "guaranteed to still work in 30 years"
  - _ph_ 5y ago
    There are several reasons. In the beginning, hg was critisized to be slow as it was written completely in python. The effect of the Linux team going with Git instead created a lot of attention to git, probably also a lot in people who were faszinated by the capabilities of git and did not care much about user friendlyness. The biggest push for git undoubtedly came from github. That is now the premier platform for hosting software, especially open source software.
  - ryandrake 5y ago
    Although it sounds like a silly reason, compare the names themselves. I don’t even know how to pronounce “mercurial” without looking it up. The word doesn’t exactly roll off the tongue like git does. And then the command itself is “hg”. WTF is up with that? I mean, ha-ha we all get the joke, but was the program made for chemists? Unnecessarily clever. Don’t underestimate the extent to which a difficult/confusing name/brand can harm adoption.
    - zabzonk 5y ago
      > I don’t even know how to pronounce “mercurial” But you do know how to pronounce "Unnecessarily"?
    - j605 5y ago
      I think for most people, they would encounter it in a science class early in life (at least for English speakers). And Hg is just the chemical symbol for mercury, https://pubchem.ncbi.nlm.nih.gov/element/Mercury#section=Identifiers https://pubchem.ncbi.nlm.nih.gov/element/Mercury#section=Ide...
    - Al-Khwarizmi 5y ago
      For non-native speakers it's much more obvious how to pronounce mercurial than git. Mercurial can only be pronounced like mercury, I guess, is there any other sensible choice? But in git, it's not obvious if the g is pronounced as in get or as in gin until you look it up.
  - lanstin 5y ago
    This also shows that quality of the technology matters. Like the discussion on the business value of Amazon's "use APIs always," using git is using a superior source code technology, designed from the ground up for distributed development by a master of distributed development; good things are enabled automatically. Linus' naming and UX choices and inconsistencies aside, the tool is awesome. That's why it wins in distributed development environments - the bazaar not the cathedral and not the bespoke engineering team hidden away in the corporation.
  - marcosdumay 5y ago
    That is solely because of network effects. Anyone of them could be the popular one, as could any of the weirder ones like darcs, even it having technical flaws (mostly fixed by now).
  - pjmlp 5y ago
    Git and Linux go hand-in-hand, so there is your killer use case right there.
- grogenaut 5y ago
  Personally I think it just needs a 3.0 where they completely rename all the commands so that they're really unified. I know there was pushback on this in the past
  - seoaeu 5y ago
    The thing with command line interfaces is that since the same interface is used by humans and computer scripts, you essentially end up with an unversioned API that you can never make breaking changes to.
    - symlinkk 5y ago
      It is versioned. There is git —-version. If your scripts break with the new version, don’t upgrade.
      - seoaeu 5y ago
        With other sorts of APIs you are given the choice between say the v1 version or the v2 version, with both endpoints being available at the same time. However, when it comes to command line programs for all practical purposes you can only have a single version installed at a time. And it of course doesn't help that essentially none of the existing scripts even check the versions of the software they run.
        grogenaut 5y ago
        This is easily fixable with a new command or envvar. This happens all the time
  - matheusmoreira 5y ago
    That would be nice but will probably never happen due to backwards compatibility. Breaking changes in git would be even worse than the slow switch to Python 3.
    - 5y ago
- cerved 5y ago
  The UX philosophy is radically different. One presupposes that you understand a lot more of the underlying system. The other tries to focus on what it is what you want to do, as opposed to how. Mercurial is less intimidating if you don't know much about internals. But tbh, when I use Mercurial I still find myself searching which command to do things. As a frequent power user, I find the Git CLI to be more useable.
SkyPuncher 5y ago
> The truth is, while we use git every day, most people really don't understand how it works. I once knew how it worked with moderate level of detail, but I simply do not need anything advanced for my day-to-day work.
- carlosf 5y ago
  Yeah that's my issue as well. I generally forget anything I don't use often and git is full of important stuff that you need infrequently.
  - lanstin 5y ago
    It's very simple, it's a graph, and you can reason what changes you want to make to the graph, and then google for the commands. Re-writing history is really only reserved for binary checkins, and that task should be assigned to whomever checked them in, so you should never need to do a destructive change. Even credentials checked in should be rotated so they aren't valid, not re-written.
handrous 5y ago
I know (or, at least, have known) how git works, in the way most people mean that (the data structures & on-disk layout, what a commit is, what a tag is, what a branch is, what HEAD is, staging, et c.). What I can't keep straight is WTF the commands are actually doing, in that low-level sense, which is a different thing, and there's approximately a 0% chance I'm ever going to use more than a tiny fraction of the commands often enough to remember that information.
- Filligree 5y ago
  Take a look at https://eagain.net/articles/git-for-computer-scientists/ https://eagain.net/articles/git-for-computer-scientists/? Maybe you've already read it, but this is what let me grok the underlying data.
  - cxr 5y ago
    The parent commenter makes it clear that they already grok the underlying data. The problem with Git, as explained so, so many times, is its horribly intuitive mapping from UI to the operations those commands preform on that model. Comments like this, which points to a resource intended to help people "grok the underlying data", has the effect of seizing the focus of conversation and implicitly retargeting it to be concerned with with people who don't understand the underlying data model. When you been through this enough times, it just comes off as incredibly annoying and a source of tiresomeness.
    - moby_click 5y ago
      I often come back to a local repository to change something and think, while I'm at it, I'll just `git pull` and end up with a non-working working directory. Surely I should know better, but I think it's also hostile to users, when the easy thing to do is often the wrong thing to do. Even worse, I'm not sure I correctly remembered the weird combination of actions and flags to use to get back to the state where I can continue with what I wanted to do in the first place. That article is a good example of the problem. It tells me `git rebase` is an easy thing to do but I better not use that distributed VCS to publish my work that way, where 'publish' probably also applies to different machines of mine.
pizza234 5y ago
Are you using Git via GUI(s)? Between my colleagues, there is a strong correlation between using a GUI, and messing up the repository. I agree that Git's UX is pretty bad (checkout overloading; overlapping between checkout and reset; push overloading... yikes!), however, I believe that in contexts where using Git is a constraint, stop using GUIs is the best strategy one can apply to improve the understanding.
- swader999 5y ago
  I agree and limit Git Gui usage to read-only use, any mods to git I use command line.
  - yxhuvud 5y ago
    Git Gui is a decent tool to compose commits, but for everything else I can't see myself using anything but the command line.
    - tcoff91 5y ago
      I do virtually everything with Magit. It's the best of both worlds IMO. You still need to actually understand git and its commands but it's like using the CLI with far fewer keystrokes and a better log interface than the CLI.
    - rjmunro 5y ago
      gitk (and similar) are great for browsing the history and figuring out what is going on. I couldn't live without it.
- dec0dedab0de 5y ago
  I use the Pycharm/Jetbrains Git GUI. At this point I can't imagine effectively handling merge conflicts any other way. EDIT: Also, I really like being able to look at a diff of every file before I commit, and easily choosing which files to include in a commit. Too often I see people on the CLI accidentally committing changes they didn't mean to, because there is no easy way to check everything at the last minute.
thatguy0900 5y ago
You're not the only one. https://xkcd.com/1597/ https://xkcd.com/1597/
pulse7 5y ago
...plus git operation names are a bit confusing (pull vs. fetch, etc.)
lisper 5y ago
I understand how git works, and I still can't use it. There are three problems: 1. Despite the claim that git never loses data, there are actually some dangerous operations that will irretrievably nuke your work with no warning. Git checkout is the canonical example. This makes me very gun-shy about doing anything that I'm not intimately familiar with. 2. Git's merge is not smart enough to realize that identical changes in two branches are not actually a conflict. I've often ended up in situations where a small bug has been fixed in two branches which then won't merge without manual intervention. This is incredibly annoying. (To be fair, this is not unique to git. But because git encourages branching more than other systems, I encounter it more when using git in idiomatic ways.) 3. This is the biggie: translating the abstract idea of what I want to do into an actual git command is a black art. The underlying model is beautiful, but the UI is atrocious. The plumbing is great. The porcelain is cracked and mildewy. There are mysterious valves and pipes all over the place when all I want is one control for the hot water and another one for the cold.
- grogenaut 5y ago
  the recommendation is actually used a different algorithm for the language that you're working in so I just use beyond compare and 99% of my simple conflicts or Auto resolved. It'd be better if these algorithms were just built into the sea Alli itself but they decided in unix style to delegate
- arxanas 5y ago
  There is a design for undoing changes to the staging area: https://github.com/arxanas/git-branchless/issues/10 https://github.com/arxanas/git-branchless/issues/10 The similar project [Jujube](https://github.com/martinvonz/jj https://github.com/martinvonz/jj) has experimented with backing up even unstaged changes after every command, and apparently it works well for them, so we could do the same in the above design. Undoing even untracked changes might be a bit much.
  - lisper 5y ago
    Yeah, this barely scratches the surface though. Take branching, which is something you're supposed to be doing all the time. So abstractly, I want to be able to get a list of my current branches, create a new branch, check out an existing branch, delete an existing branch, and maybe rename a branch. I would expect the commands for these operations to be something like: git branch list git branch create [name] git branch delete [name] git branch rename [old-name] [new-name] We can argue over whether checking out a branch should be "git branch checkout [name]" or just "git checkout [name]", but in either case, if I have unsaved changes in my working directory, I would expect to at least get a warning about this before that work got clobbered. None of these things are actually the case. Git checkout will clobber unsaved changes in my working directory. "Git branch list" is just "git branch". "git branch create" is "git branch [name]". So creating a branch is the SAME COMMAND as the one you use to produce a list of current branches, just with an argument. Madness. And this is the rule, not the exception. Minor variations on a theme can result in radically different commands with various mysterious arguments. There is no rhyme or reason or regularity. The only way to know is to look it up.
Hamuko 5y ago
>The truth is, while we use git every day, most people really don't understand how it works. Most people don't know how the Internet works and yet it's widely used. You don't need to understand the inner workings of git. You just need to know some commands and some basic concepts.
- matheusmoreira 5y ago
  > Most people don't know how the Internet works and yet it's widely used. Yeah. I've met many developers who have no idea what a cookie even is, people who have never read a single IETF RFC.
  - uvesten 5y ago
    Me too, far too often. Those developers are most often negative contributors...
- agucova 5y ago
  The problem is not knowing git internal can very easily backfire by deleting data, rewriting history, etc
jdmichal 5y ago
All my git training starts with a whiteboard and drawing out a commit tree and branch pointers. I only talk about the commands in reference to the drawings, not the other way around. Most commands are manipulating this commit tree, so it gives a visual to latch understanding onto. `git reflog` shows the commits where your current branch pointer has been. `git reset --hard` moves your current branch pointer and to the given commit, then modifies your working directory to match that commit. `--soft` moves the branch pointer and does not modify your working directory. `--mixed` moves the branch pointer, does not modify your working directory, but does clear staging.
lugged 5y ago
I come across this attitude a lot. Usually my response is if you use something daily, and you know you lack the skills to use it effectively, why don't you improve your knowledge and seek out training or education? Do you treat a new programming language or framework with the same disdain? I know I'm gonna get some hate for pointing this out but this same disdain is what causes things like the branchless workflow. A workflow that hamstrings yourself to git stash as a poor man's branch. I get it, I used that as crutch for years, then I spent some time learning git properly. Most people haven't even watched the one hour talk where Linus talks about the design and building of git. One hour might sound like a lot to understand why branching is so amazing, and why distributed source control is hard but it's a tool I've used for almost a decade and won't stop using for the next decade. I think it was worth it.
- Ensorceled 5y ago
  At one time I was an expert in 'C'. I was the goto guy at our company for porting and performance issues and was often just handed the entire project if it involved porting. I have no memory of any of that beyond the basics now. Git is like that. There is no way I will remember commands I only use once a quarter or so when something goes wrong.
  - lugged 5y ago
    I don't know what to tell you, commit more code? Branch more? Work in teams? Maybe git isn't the right tool for you? I have a set of commands I use multiple times a day, for everything else there are manuals and docs to reference. Git branch, commit, rebase, merge, clone, check out, pull, push, submodule, remote, and maybe a couple more, are there specific commands you don't use daily? Other than remote and submodule I use all of those almost daily.
    - megameter 5y ago
      That's nice, but most of us here are version control consumers, not version control professionals. We need something that has very few knobs to turn because our job is focused around delivering value through other tasks. Git is highly professionalized. It has layers of modal state. That is built into the operating model. It is made for Linus Torvalds, a professional merger of code. If you are using all of those commands "almost daily", you are a professional code-merger too.
eric4smith 5y ago
I do use git every single day. It’s a super valuable tool. Maybe my bad on not taking a course or reading the manual from cover to cover.
MayeulC 5y ago
> What does "git reflog" or "git reset --hard ...." do? What are the implications? This is supposed to be covered in `man git reflog` and `man git reset --hard`. I admit that it could be more readable though. Currently, it's more of a technically-correct introduction than a layman's. I guess it's really more of a documentation for experts. Some have made fun of this: https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/ In layman's terms, `git reflog` is the history of the positions you were at: you'll see every commit you've visited recently, so as long as something was committed, you won't lose it. It's here in case you lose some commit identifier (for instance you finished rebasing but are not happy with the result: the branch now points to the sad commit. Grab the reflog, copy the commit identifier and reset the branch to point it to where it was before). And `git reset --hard`... `git reset` changes the branch "tip" (pointer) to another commit: the commit tree always exists. Branches are "named commits". `git reset` moves these tags around. The `--hard` part "just" replaces the entire content of your working directory (including non-committed changes) to the commit you give as a parameter. With no parameters, it just resets to the latest commit in that branch, so it's like saying "clean my working directory back to what was committed, discard my changes". Perfect for losing work. I agree that git "porcelain" commands are sometimes ill-named and a bit counter-intuitive to grasp. For me, learning git paid of (sort of: I don't spend time fighting my issues, I spend it helping others fix theirs). I'm keeping an eye on better-designed alternatives like pijul. mercurial is interesting and has better-named command, but I sunk some time learning git already, and know it better, so hg has very little more to offer to me.
- bentinata 5y ago
  Minor additions; branches are named commits that move along as you commit, while tags are named commits that stay.
reacharavindh 5y ago
+1. I wonder if it is possible for someone to write a meta-CLI that works on top of git like “git for humans”. While, still leaving the power for expert users
sngz 5y ago
this is why i was so sad when mercurial support ended. I loved using mercurial it just works and it was so intuitive. My firm last year switched all projects over to github and it's been a pain, I learned it no problem but still have to google the occasional thing, but I spend most of my time fixing other people messing up the repo.
jozvolskyef 5y ago
Have you tried reading the manual[1]? I read it cover to cover once and it is invaluable because it gives you the ability to understand and describe what you're trying to achieve. The solution is always one search away if you know how to ask. [1]: https://mirrors.edge.kernel.org/pub/software/scm/git/docs/user-manual.html https://mirrors.edge.kernel.org/pub/software/scm/git/docs/us...
ycken 5y ago
> The truth is, while we use git every day, most people really don't understand how it works. It is a tool. One should not need to understand the inner workings of a tool to use it. How many APIs do we use where knowing how it does what it does is required? Whether it's Stripe or Node or Bundler or ..., the user does not have to know what happens inside. The need for incantations makes some people feel powerful or exclusive. I just want my tools to do their job so I can focus on doing mine.
cosmodisk 5y ago
I suggest to try this: www.pluralsight.com/courses/how-git-works. It covers the fundamentals behind git but without the usual 'nose up in the sky attitude and elitism' that could be seen in many books or articles about it.
mrslave 5y ago
Points for honesty. Obligatory XKCD [0]. FYI: `git reflog` saves your ass when you accidentally delete a branch locally, only to then realize there were valuable commits yet to be pushed to master! How it does it is another matter. Systems enabling high usefulness with little education (i.e. shallow learning curve, at least initially) and then incremental education are ideal. This isn't essential, just desirable. Git can err a little on the steep learning curve/mystery black box side of things a bit. But it is still a damn fine tool. [0] https://xkcd.com/1597/ https://xkcd.com/1597/
minusSeven 5y ago
90% of the time all you need from version control system is update-> make your changes-> commit/push your changes You just don't need to learn unless you really require it. And even if you do learn you will eventually forget if you don't use all the features. Its not hard to see why people don't even bother.
johnisgood 5y ago
> What does "git reflog" or "git reset --hard ...." do? What are the implications? If you have ever done a "git reset" (which implies --soft), then you should know what "hard" in this case means. I am not sure, I knew that it would most likely get rid of my uncommitted changes. I "git stash", then "git stash pop". Do not run anything without knowing what it does, you should consult the manual page: "man git reset". Search for "--hard", and you get: --hard Resets the index and working tree. Any changes to tracked files in the working tree since <commit> are discarded. I do not find myself reading the manual pages that often anymore. That said, I do have my own notes which I read sometimes, just to be sure. Slightly off-topic, but I love working with meld! If I do a "git rebase --onto [...]" I do not get "meld" open automatically, you gotta type "git mergetool" to resolve conflicts.
foxyv 5y ago
I've noticed this. Every time I try to explain to people about hash maps, GIT blobs and commit trees their eyes glaze over. If you are ever curious though the documentation is kinda cool. https://git-scm.com/book/en/v2/Git-Internals-Git-Objects https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

sebmellen 5y ago

For some reason people love to defend the obscure and strange and oftentimes objectively terrible Git CLI. I’ve found Mercurial much more straightforward for my (mundane and boring but prevalent) use cases, and I lament that it isn’t more widely used.

zibzab 5y ago
Every single time we are discussing git this comment shows up. But why is one popular when the other one is so much better? I guess we will never know
- disgruntledphd2 5y ago
  GitHub is the reason. Turns out giving beer to developers globally is an effective way to get a technology adopted.
  - zabzonk 5y ago
    Bitbucket used to provide free (and pretty good) Mercurial hosting.
    - oblio 5y ago
      Bitbucket had a much crappier UI.
      - zabzonk 5y ago
        Actually, one of the reasons I preferred hg to git is that Windows explorer GUI integration back then was far superior to gits, which was buggy as hell.
        ivanbakel 5y ago
        This doesn't seem relevant to the comment you're replying to. Bitbucket's web UI sucks, which is why it didn't have the effect on Mercurial that Github had on git. Having used Bitbucket and GitHub, I think GH is much nicer - both in the sense of basic stuff like page loads being faster, and in terms of features. And since it's the main tool that everyone on the development team spends their time on for communication & collaboration, those things really matter.
        mixmastamyk 5y ago
        Also, remember to compare the sites ten years ago rather than today.
- zabzonk 5y ago
  The Torvalds effect.
  - zibzab 5y ago
    I know you imply, but this could also be interpreted as "battle proven" or how about "guaranteed to still work in 30 years"
- _ph_ 5y ago
  There are several reasons. In the beginning, hg was critisized to be slow as it was written completely in python. The effect of the Linux team going with Git instead created a lot of attention to git, probably also a lot in people who were faszinated by the capabilities of git and did not care much about user friendlyness. The biggest push for git undoubtedly came from github. That is now the premier platform for hosting software, especially open source software.
- ryandrake 5y ago
  Although it sounds like a silly reason, compare the names themselves. I don’t even know how to pronounce “mercurial” without looking it up. The word doesn’t exactly roll off the tongue like git does. And then the command itself is “hg”. WTF is up with that? I mean, ha-ha we all get the joke, but was the program made for chemists? Unnecessarily clever. Don’t underestimate the extent to which a difficult/confusing name/brand can harm adoption.
  - zabzonk 5y ago
    > I don’t even know how to pronounce “mercurial” But you do know how to pronounce "Unnecessarily"?
  - j605 5y ago
    I think for most people, they would encounter it in a science class early in life (at least for English speakers). And Hg is just the chemical symbol for mercury, https://pubchem.ncbi.nlm.nih.gov/element/Mercury#section=Identifiers https://pubchem.ncbi.nlm.nih.gov/element/Mercury#section=Ide...
  - Al-Khwarizmi 5y ago
    For non-native speakers it's much more obvious how to pronounce mercurial than git. Mercurial can only be pronounced like mercury, I guess, is there any other sensible choice? But in git, it's not obvious if the g is pronounced as in get or as in gin until you look it up.
- lanstin 5y ago
  This also shows that quality of the technology matters. Like the discussion on the business value of Amazon's "use APIs always," using git is using a superior source code technology, designed from the ground up for distributed development by a master of distributed development; good things are enabled automatically. Linus' naming and UX choices and inconsistencies aside, the tool is awesome. That's why it wins in distributed development environments - the bazaar not the cathedral and not the bespoke engineering team hidden away in the corporation.
- marcosdumay 5y ago
  That is solely because of network effects. Anyone of them could be the popular one, as could any of the weirder ones like darcs, even it having technical flaws (mostly fixed by now).
- pjmlp 5y ago
  Git and Linux go hand-in-hand, so there is your killer use case right there.
grogenaut 5y ago
Personally I think it just needs a 3.0 where they completely rename all the commands so that they're really unified. I know there was pushback on this in the past
- seoaeu 5y ago
  The thing with command line interfaces is that since the same interface is used by humans and computer scripts, you essentially end up with an unversioned API that you can never make breaking changes to.
  - symlinkk 5y ago
    It is versioned. There is git —-version. If your scripts break with the new version, don’t upgrade.
    - seoaeu 5y ago
      With other sorts of APIs you are given the choice between say the v1 version or the v2 version, with both endpoints being available at the same time. However, when it comes to command line programs for all practical purposes you can only have a single version installed at a time. And it of course doesn't help that essentially none of the existing scripts even check the versions of the software they run.
      - grogenaut 5y ago
        This is easily fixable with a new command or envvar. This happens all the time
- matheusmoreira 5y ago
  That would be nice but will probably never happen due to backwards compatibility. Breaking changes in git would be even worse than the slow switch to Python 3.
  - 5y ago
cerved 5y ago
The UX philosophy is radically different. One presupposes that you understand a lot more of the underlying system. The other tries to focus on what it is what you want to do, as opposed to how. Mercurial is less intimidating if you don't know much about internals. But tbh, when I use Mercurial I still find myself searching which command to do things. As a frequent power user, I find the Git CLI to be more useable.

SkyPuncher 5y ago

> The truth is, while we use git every day, most people really don't understand how it works. I once knew how it worked with moderate level of detail, but I simply do not need anything advanced for my day-to-day work.

carlosf 5y ago
Yeah that's my issue as well. I generally forget anything I don't use often and git is full of important stuff that you need infrequently.
- lanstin 5y ago
  It's very simple, it's a graph, and you can reason what changes you want to make to the graph, and then google for the commands. Re-writing history is really only reserved for binary checkins, and that task should be assigned to whomever checked them in, so you should never need to do a destructive change. Even credentials checked in should be rotated so they aren't valid, not re-written.

handrous 5y ago

I know (or, at least, have known) how git works, in the way most people mean that (the data structures & on-disk layout, what a commit is, what a tag is, what a branch is, what HEAD is, staging, et c.). What I can't keep straight is WTF the commands are actually doing, in that low-level sense, which is a different thing, and there's approximately a 0% chance I'm ever going to use more than a tiny fraction of the commands often enough to remember that information.

Filligree 5y ago
Take a look at https://eagain.net/articles/git-for-computer-scientists/ https://eagain.net/articles/git-for-computer-scientists/? Maybe you've already read it, but this is what let me grok the underlying data.
- cxr 5y ago
  The parent commenter makes it clear that they already grok the underlying data. The problem with Git, as explained so, so many times, is its horribly intuitive mapping from UI to the operations those commands preform on that model. Comments like this, which points to a resource intended to help people "grok the underlying data", has the effect of seizing the focus of conversation and implicitly retargeting it to be concerned with with people who don't understand the underlying data model. When you been through this enough times, it just comes off as incredibly annoying and a source of tiresomeness.
  - moby_click 5y ago
    I often come back to a local repository to change something and think, while I'm at it, I'll just `git pull` and end up with a non-working working directory. Surely I should know better, but I think it's also hostile to users, when the easy thing to do is often the wrong thing to do. Even worse, I'm not sure I correctly remembered the weird combination of actions and flags to use to get back to the state where I can continue with what I wanted to do in the first place. That article is a good example of the problem. It tells me `git rebase` is an easy thing to do but I better not use that distributed VCS to publish my work that way, where 'publish' probably also applies to different machines of mine.

pizza234 5y ago

Are you using Git via GUI(s)? Between my colleagues, there is a strong correlation between using a GUI, and messing up the repository. I agree that Git's UX is pretty bad (checkout overloading; overlapping between checkout and reset; push overloading... yikes!), however, I believe that in contexts where using Git is a constraint, stop using GUIs is the best strategy one can apply to improve the understanding.

swader999 5y ago
I agree and limit Git Gui usage to read-only use, any mods to git I use command line.
- yxhuvud 5y ago
  Git Gui is a decent tool to compose commits, but for everything else I can't see myself using anything but the command line.
  - tcoff91 5y ago
    I do virtually everything with Magit. It's the best of both worlds IMO. You still need to actually understand git and its commands but it's like using the CLI with far fewer keystrokes and a better log interface than the CLI.
  - rjmunro 5y ago
    gitk (and similar) are great for browsing the history and figuring out what is going on. I couldn't live without it.
dec0dedab0de 5y ago
I use the Pycharm/Jetbrains Git GUI. At this point I can't imagine effectively handling merge conflicts any other way. EDIT: Also, I really like being able to look at a diff of every file before I commit, and easily choosing which files to include in a commit. Too often I see people on the CLI accidentally committing changes they didn't mean to, because there is no easy way to check everything at the last minute.

thatguy0900 5y ago

You're not the only one. https://xkcd.com/1597/ https://xkcd.com/1597/

pulse7 5y ago

...plus git operation names are a bit confusing (pull vs. fetch, etc.)

lisper 5y ago

I understand how git works, and I still can't use it. There are three problems: 1. Despite the claim that git never loses data, there are actually some dangerous operations that will irretrievably nuke your work with no warning. Git checkout is the canonical example. This makes me very gun-shy about doing anything that I'm not intimately familiar with. 2. Git's merge is not smart enough to realize that identical changes in two branches are not actually a conflict. I've often ended up in situations where a small bug has been fixed in two branches which then won't merge without manual intervention. This is incredibly annoying. (To be fair, this is not unique to git. But because git encourages branching more than other systems, I encounter it more when using git in idiomatic ways.) 3. This is the biggie: translating the abstract idea of what I want to do into an actual git command is a black art. The underlying model is beautiful, but the UI is atrocious. The plumbing is great. The porcelain is cracked and mildewy. There are mysterious valves and pipes all over the place when all I want is one control for the hot water and another one for the cold.

grogenaut 5y ago
the recommendation is actually used a different algorithm for the language that you're working in so I just use beyond compare and 99% of my simple conflicts or Auto resolved. It'd be better if these algorithms were just built into the sea Alli itself but they decided in unix style to delegate
arxanas 5y ago
There is a design for undoing changes to the staging area: https://github.com/arxanas/git-branchless/issues/10 https://github.com/arxanas/git-branchless/issues/10 The similar project [Jujube](https://github.com/martinvonz/jj https://github.com/martinvonz/jj) has experimented with backing up even unstaged changes after every command, and apparently it works well for them, so we could do the same in the above design. Undoing even untracked changes might be a bit much.
- lisper 5y ago
  Yeah, this barely scratches the surface though. Take branching, which is something you're supposed to be doing all the time. So abstractly, I want to be able to get a list of my current branches, create a new branch, check out an existing branch, delete an existing branch, and maybe rename a branch. I would expect the commands for these operations to be something like: git branch list git branch create [name] git branch delete [name] git branch rename [old-name] [new-name] We can argue over whether checking out a branch should be "git branch checkout [name]" or just "git checkout [name]", but in either case, if I have unsaved changes in my working directory, I would expect to at least get a warning about this before that work got clobbered. None of these things are actually the case. Git checkout will clobber unsaved changes in my working directory. "Git branch list" is just "git branch". "git branch create" is "git branch [name]". So creating a branch is the SAME COMMAND as the one you use to produce a list of current branches, just with an argument. Madness. And this is the rule, not the exception. Minor variations on a theme can result in radically different commands with various mysterious arguments. There is no rhyme or reason or regularity. The only way to know is to look it up.

Hamuko 5y ago

>The truth is, while we use git every day, most people really don't understand how it works. Most people don't know how the Internet works and yet it's widely used. You don't need to understand the inner workings of git. You just need to know some commands and some basic concepts.

matheusmoreira 5y ago
> Most people don't know how the Internet works and yet it's widely used. Yeah. I've met many developers who have no idea what a cookie even is, people who have never read a single IETF RFC.
- uvesten 5y ago
  Me too, far too often. Those developers are most often negative contributors...
agucova 5y ago
The problem is not knowing git internal can very easily backfire by deleting data, rewriting history, etc

jdmichal 5y ago

All my git training starts with a whiteboard and drawing out a commit tree and branch pointers. I only talk about the commands in reference to the drawings, not the other way around. Most commands are manipulating this commit tree, so it gives a visual to latch understanding onto. `git reflog` shows the commits where your current branch pointer has been. `git reset --hard` moves your current branch pointer and to the given commit, then modifies your working directory to match that commit. `--soft` moves the branch pointer and does not modify your working directory. `--mixed` moves the branch pointer, does not modify your working directory, but does clear staging.

lugged 5y ago

I come across this attitude a lot. Usually my response is if you use something daily, and you know you lack the skills to use it effectively, why don't you improve your knowledge and seek out training or education? Do you treat a new programming language or framework with the same disdain? I know I'm gonna get some hate for pointing this out but this same disdain is what causes things like the branchless workflow. A workflow that hamstrings yourself to git stash as a poor man's branch. I get it, I used that as crutch for years, then I spent some time learning git properly. Most people haven't even watched the one hour talk where Linus talks about the design and building of git. One hour might sound like a lot to understand why branching is so amazing, and why distributed source control is hard but it's a tool I've used for almost a decade and won't stop using for the next decade. I think it was worth it.

Ensorceled 5y ago
At one time I was an expert in 'C'. I was the goto guy at our company for porting and performance issues and was often just handed the entire project if it involved porting. I have no memory of any of that beyond the basics now. Git is like that. There is no way I will remember commands I only use once a quarter or so when something goes wrong.
- lugged 5y ago
  I don't know what to tell you, commit more code? Branch more? Work in teams? Maybe git isn't the right tool for you? I have a set of commands I use multiple times a day, for everything else there are manuals and docs to reference. Git branch, commit, rebase, merge, clone, check out, pull, push, submodule, remote, and maybe a couple more, are there specific commands you don't use daily? Other than remote and submodule I use all of those almost daily.
  - megameter 5y ago
    That's nice, but most of us here are version control consumers, not version control professionals. We need something that has very few knobs to turn because our job is focused around delivering value through other tasks. Git is highly professionalized. It has layers of modal state. That is built into the operating model. It is made for Linus Torvalds, a professional merger of code. If you are using all of those commands "almost daily", you are a professional code-merger too.

eric4smith 5y ago

I do use git every single day. It’s a super valuable tool. Maybe my bad on not taking a course or reading the manual from cover to cover.

MayeulC 5y ago

> What does "git reflog" or "git reset --hard ...." do? What are the implications? This is supposed to be covered in `man git reflog` and `man git reset --hard`. I admit that it could be more readable though. Currently, it's more of a technically-correct introduction than a layman's. I guess it's really more of a documentation for experts. Some have made fun of this: https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/ In layman's terms, `git reflog` is the history of the positions you were at: you'll see every commit you've visited recently, so as long as something was committed, you won't lose it. It's here in case you lose some commit identifier (for instance you finished rebasing but are not happy with the result: the branch now points to the sad commit. Grab the reflog, copy the commit identifier and reset the branch to point it to where it was before). And `git reset --hard`... `git reset` changes the branch "tip" (pointer) to another commit: the commit tree always exists. Branches are "named commits". `git reset` moves these tags around. The `--hard` part "just" replaces the entire content of your working directory (including non-committed changes) to the commit you give as a parameter. With no parameters, it just resets to the latest commit in that branch, so it's like saying "clean my working directory back to what was committed, discard my changes". Perfect for losing work. I agree that git "porcelain" commands are sometimes ill-named and a bit counter-intuitive to grasp. For me, learning git paid of (sort of: I don't spend time fighting my issues, I spend it helping others fix theirs). I'm keeping an eye on better-designed alternatives like pijul. mercurial is interesting and has better-named command, but I sunk some time learning git already, and know it better, so hg has very little more to offer to me.

bentinata 5y ago
Minor additions; branches are named commits that move along as you commit, while tags are named commits that stay.

reacharavindh 5y ago

+1. I wonder if it is possible for someone to write a meta-CLI that works on top of git like “git for humans”. While, still leaving the power for expert users

sngz 5y ago

this is why i was so sad when mercurial support ended. I loved using mercurial it just works and it was so intuitive. My firm last year switched all projects over to github and it's been a pain, I learned it no problem but still have to google the occasional thing, but I spend most of my time fixing other people messing up the repo.

jozvolskyef 5y ago

Have you tried reading the manual[1]? I read it cover to cover once and it is invaluable because it gives you the ability to understand and describe what you're trying to achieve. The solution is always one search away if you know how to ask. [1]: https://mirrors.edge.kernel.org/pub/software/scm/git/docs/user-manual.html https://mirrors.edge.kernel.org/pub/software/scm/git/docs/us...

ycken 5y ago

> The truth is, while we use git every day, most people really don't understand how it works. It is a tool. One should not need to understand the inner workings of a tool to use it. How many APIs do we use where knowing how it does what it does is required? Whether it's Stripe or Node or Bundler or ..., the user does not have to know what happens inside. The need for incantations makes some people feel powerful or exclusive. I just want my tools to do their job so I can focus on doing mine.

cosmodisk 5y ago

I suggest to try this: www.pluralsight.com/courses/how-git-works. It covers the fundamentals behind git but without the usual 'nose up in the sky attitude and elitism' that could be seen in many books or articles about it.

mrslave 5y ago

Points for honesty. Obligatory XKCD [0]. FYI: `git reflog` saves your ass when you accidentally delete a branch locally, only to then realize there were valuable commits yet to be pushed to master! How it does it is another matter. Systems enabling high usefulness with little education (i.e. shallow learning curve, at least initially) and then incremental education are ideal. This isn't essential, just desirable. Git can err a little on the steep learning curve/mystery black box side of things a bit. But it is still a damn fine tool. [0] https://xkcd.com/1597/ https://xkcd.com/1597/

minusSeven 5y ago

90% of the time all you need from version control system is update-> make your changes-> commit/push your changes You just don't need to learn unless you really require it. And even if you do learn you will eventually forget if you don't use all the features. Its not hard to see why people don't even bother.

johnisgood 5y ago

> What does "git reflog" or "git reset --hard ...." do? What are the implications? If you have ever done a "git reset" (which implies --soft), then you should know what "hard" in this case means. I am not sure, I knew that it would most likely get rid of my uncommitted changes. I "git stash", then "git stash pop". Do not run anything without knowing what it does, you should consult the manual page: "man git reset". Search for "--hard", and you get: --hard Resets the index and working tree. Any changes to tracked files in the working tree since <commit> are discarded. I do not find myself reading the manual pages that often anymore. That said, I do have my own notes which I read sometimes, just to be sure. Slightly off-topic, but I love working with meld! If I do a "git rebase --onto [...]" I do not get "meld" open automatically, you gotta type "git mergetool" to resolve conflicts.

foxyv 5y ago

I've noticed this. Every time I try to explain to people about hash maps, GIT blobs and commit trees their eyes glaze over. If you are ever curious though the documentation is kinda cool. https://git-scm.com/book/en/v2/Git-Internals-Git-Objects https://git-scm.com/book/en/v2/Git-Internals-Git-Objects