9 ms·

>But IMO it isn't because Git is hard, but because they don't have to truly understand Git to use it. That's how easy it is. A copy&paste of my previous commen

by jasode 6y ago

>But IMO it isn't because Git is hard, but because they don't have to truly understand Git to use it. That's how easy it is. A copy&paste of my previous comment: Everybody's brain is different but I actually understand all of git's internals (the "plumbing") but it doesn't help me with the git CLI (the "porcelain"). Yes, I know that Git is a DAG (Directed Acyclic Graph), and that HEAD is a pointer, and the file format of BLOBs and SHAs, etc. If I were to implement a DVCS, I would inevitably end up reinventing many of the same technical architecture decisions that Linus came up with. But none of that insider knowledge really helps me remember git syntax if I haven't been using it in more than a month. Even though I grok git's mental model, I still can't answer the top-voted "git" questions on Stackoverflow without a cheat sheet: https://stackoverflow.com/questions/tagged/git?tab=Votes https://stackoverflow.com/questions/tagged/git?tab=Votes The git UI and unintuitive syntax is just too hard for me to remember unless I use it every day. Also to add.. the concept of "git index" as a staging area adds some complexity as well. Yes, there are good reasons for it (1) it lets one craft a specific subset instead of all changed files to commit and (2) it's a performance boost because a Big-O type O(n) loop runs faster when iterating through the staging index (small "n" of dozens) to detect changes instead of looping through the entire source code tree (large "n" of 10,000+ files in a big repo). But that flexibility adds an extra cognitive burden when a newbie just wants to save a "backup snapshot of the repo". For a newbie, the extra indirection layer of "staging index" seems superfluous and confusing. That's why some present an alternative porcelain to git that doesn't expose the staging concept: e.g. https://gitless.com/ https://gitless.com/ (To clarify, I'm not recommending Gitless but just giving an example of why some felt motivated to simplify Git's porcelain.)

nicoburns 6y ago
Totally agree on the "staging area". I've always thought that the staging area should only activate when you `git add` or otherwise add files to it. If there are no staged files, then git commit should act like git commit -A.
- whizzter 6y ago
  Oh hell no, Visual Studio has this behaviour by default (commit all changes if nothing staged) and what we end up with is that some people keep checking in various experiments and privately modified launch config files (that should not be in the repo anyhow but that's another story related to the tools) that end up causing a lot of unnecessary merge conflicts when you pull in their changes (where you were really only expecting some other part).
  - nicoburns 6y ago
    We deal with this via code review. Anything with such files is going to get instantly rejected. And people soon learn not to do it.
    - tremon 6y ago
      So with every new hire, you have burden the reviewer again? Wouldn't it be better to make the default so that Visual Studio burdens the primary developer, instead of the reviewer?
    - kubanczyk 6y ago
      We prefer to automate everything that's automatable, and then a bit more, because reviewing is hard work.
karatinversion 6y ago
> Even though I grok git's mental model, I still can't answer the top-voted "git" questions on Stackoverflow without a cheat sheet: https://stackoverflow.com/questions/tagged/git?tab=Votes https://stackoverflow.com/questions/tagged/git?tab=Votes This was surprising to me, and shows how different people's experiences of git can be. My workplace switched to git from an obsolete centralized VCS earlier this year, and I could easily answer these. Something like this is probably where the line between those in this thread who agree that git is too hard, and those who think the detractors are just lazy and stupid, runs. Folks, people are more different than you expect!
- jobigoud 6y ago
  > I could easily answer these Maybe you find it easy because you don't see the subtleties. The answer to reverting the last commit for example can't really be that simple because it depends on what the user really wants to do. Do you want to keep the changes in staging? Reset the index but keep the changes in your working copy? Or reset the files to their state at the previous commit?
leobakerhytch 6y ago
I fully agree that the default porcelain has poor UX for managing the staging area, but doesn’t a porcelain without it encourage overly large commits? All sorts of workflows become substantially more difficult (if not impossible) with kitchen sink commits. Undoing a single-line change, for instance. I dislike large pull requests, let alone commits that introduce a half dozen different changes. Sure, if you’re really disciplined you can produce small commits without staging, by committing as you go along, but you’re breaking flow every time you commit in this style. I say all this because I would love a CLI that has half-way sane handling of (e.g.) restoring staged, deleted files; doesn’t conflate restoring files with switching branches; has consistency of flags between commands (such as commit vs stash message); etc., etc. I should try gitless ;)
- lmm 6y ago
  > I fully agree that the default porcelain has poor UX for managing the staging area, but doesn’t a porcelain without it encourage overly large commits? No, I'd say the opposite. The staging area encourages me to think that I can make my change and split it up into logical commits afterwards, even though I know I'll actually just give up and make it a big commit. When I didn't know about the staging area and just committed whenever I could, I produced better, smaller commits.
  - lsaferite 6y ago
    > The staging area encourages me to think that I can make my change and split it up into logical commits afterwards, even though I know I'll actually just give up and make it a big commit. That sounds like a personal discipline problem and not a poor tool.
    - lmm 6y ago
      The whole point of a tool like git is so that I don't have to expend personal discipline.
      - lsaferite 6y ago
3np 6y ago
Maybe what we really need is not a new VCS, just a new CLI frontend for git.
- thrwyoilarticle 6y ago
  If it was easy to create a frontend that worked seemlessly on a git repo then it would have been done already.
  - 3np 6y ago
    Buzzkill! I think it's more a matter of that those who are in a position to do so are used enough with git-cli that they are happy with the status quo.
  - couchand 6y ago
    It has been. There are numerous such projects; gitless comes to mind since somebody else brought it up in a comment here.
    - thrwyoilarticle 6y ago
      So the problem is solved and the OP blog shouldn't exist?
      - 3np 6y ago
        Your point being?
thaumasiotes 6y ago
> But that flexibility adds an extra cognitive burden when a newbie just wants to save a "backup snapshot of the repo". Simple needs have simple answers. git add . git commit -am '2020-11-17' Sure, you can ask "why are there two commands?", but this is not so much an issue of cognitive burden as of typing burden. If you only want one thing, you only have to know how to do one thing. If you don't want to know why the procedure does what it does, you don't have to.
- Qwertious 6y ago
  When you're writing into a text file and then save it, you don't have to manually select what lines or pages you're saving - you're saving all of it. This is the mental model 99% of newbies will have for something that basically pledges to save and sync each version of your files. Deviating from the user's mental model will create roadbumps and should not be done without a very strong rationale. Especially not for a feature that's fundamentally optional.
  - tremon 6y ago
    When you're writing into a text file and then save it, you don't have to manually select what lines or pages you're saving - you're saving all of it So? When you're saving a file, you're also overwriting its entire contents. Good luck reverting back to the file before you saved it. There is no automatic model for "this change is worth tracking" and "this change is not important enough to annotate". That's the model that git is enabling, and it has nothing to do with the "save" button in an editor. If anything, it has more to do with the "track changes" feature in Word, but more powerful because it allows you to group multiple edits in the same change.
  - thaumasiotes 6y ago
    > When you're writing into a text file and then save it, you don't have to manually select what lines or pages you're saving - you're saving all of it. I don't understand the point you're trying to make; this is just as true of the command I gave.
- rsync 6y ago
hakre 6y ago
For snapshots use backups. Git is not a backup. For the questions, what's bad with quick help on SO? It's maybe less effective than reading the documentation that ships with git itself but for sure much more popular and less to read. Git truly is a command-line utility, little known is that it ships with more than one gui in the base package out of the box. handling the staging area with git gui for example is straight forward unless you have more than 5000 unstaged files, then the gui informs you about it's limit and mass handling is far easier on the command-line anyway.
grumple 6y ago
> Even though I grok git's mental model, I still can't answer the top-voted "git" questions on Stackoverflow without a cheat sheet This sounds like you just don't use or need those things much, which is fine if it works for you. Of the top 10, I can answer 9 of them without doing any research because I've used these commands a lot and they've become a part of my workflow. The one I'm missing? I've never renamed a git branch. If I needed to, I'd probably just do git branch --help or google it and figure it out in five seconds. You don't need to commit every command of the program to memory. Just like anything else in tech, knowing how to find the knowledge you need is good enough.
HourglassFR 6y ago
I feel the same way, I understand git pretty well but cannot for the life of me use the CLI. Fortunatly there are some pretty good GUI around, I personally use GitExtensions and find it suits my brain nicely. Its windows only though, not a problem for me since my work forces me to use Windows and I don't code at home but surely they are nice git GUI for Linux no ?

by jasode 6y ago

nicoburns 6y ago

Totally agree on the "staging area". I've always thought that the staging area should only activate when you `git add` or otherwise add files to it. If there are no staged files, then git commit should act like git commit -A.

whizzter 6y ago
Oh hell no, Visual Studio has this behaviour by default (commit all changes if nothing staged) and what we end up with is that some people keep checking in various experiments and privately modified launch config files (that should not be in the repo anyhow but that's another story related to the tools) that end up causing a lot of unnecessary merge conflicts when you pull in their changes (where you were really only expecting some other part).
- nicoburns 6y ago
  We deal with this via code review. Anything with such files is going to get instantly rejected. And people soon learn not to do it.
  - tremon 6y ago
    So with every new hire, you have burden the reviewer again? Wouldn't it be better to make the default so that Visual Studio burdens the primary developer, instead of the reviewer?
  - kubanczyk 6y ago
    We prefer to automate everything that's automatable, and then a bit more, because reviewing is hard work.

karatinversion 6y ago

> Even though I grok git's mental model, I still can't answer the top-voted "git" questions on Stackoverflow without a cheat sheet: https://stackoverflow.com/questions/tagged/git?tab=Votes https://stackoverflow.com/questions/tagged/git?tab=Votes This was surprising to me, and shows how different people's experiences of git can be. My workplace switched to git from an obsolete centralized VCS earlier this year, and I could easily answer these. Something like this is probably where the line between those in this thread who agree that git is too hard, and those who think the detractors are just lazy and stupid, runs. Folks, people are more different than you expect!

jobigoud 6y ago
> I could easily answer these Maybe you find it easy because you don't see the subtleties. The answer to reverting the last commit for example can't really be that simple because it depends on what the user really wants to do. Do you want to keep the changes in staging? Reset the index but keep the changes in your working copy? Or reset the files to their state at the previous commit?

leobakerhytch 6y ago

I fully agree that the default porcelain has poor UX for managing the staging area, but doesn’t a porcelain without it encourage overly large commits? All sorts of workflows become substantially more difficult (if not impossible) with kitchen sink commits. Undoing a single-line change, for instance. I dislike large pull requests, let alone commits that introduce a half dozen different changes. Sure, if you’re really disciplined you can produce small commits without staging, by committing as you go along, but you’re breaking flow every time you commit in this style. I say all this because I would love a CLI that has half-way sane handling of (e.g.) restoring staged, deleted files; doesn’t conflate restoring files with switching branches; has consistency of flags between commands (such as commit vs stash message); etc., etc. I should try gitless ;)

lmm 6y ago
> I fully agree that the default porcelain has poor UX for managing the staging area, but doesn’t a porcelain without it encourage overly large commits? No, I'd say the opposite. The staging area encourages me to think that I can make my change and split it up into logical commits afterwards, even though I know I'll actually just give up and make it a big commit. When I didn't know about the staging area and just committed whenever I could, I produced better, smaller commits.
- lsaferite 6y ago
  > The staging area encourages me to think that I can make my change and split it up into logical commits afterwards, even though I know I'll actually just give up and make it a big commit. That sounds like a personal discipline problem and not a poor tool.
  - lmm 6y ago
    The whole point of a tool like git is so that I don't have to expend personal discipline.
    - lsaferite 6y ago

3np 6y ago

Maybe what we really need is not a new VCS, just a new CLI frontend for git.

thrwyoilarticle 6y ago
If it was easy to create a frontend that worked seemlessly on a git repo then it would have been done already.
- 3np 6y ago
  Buzzkill! I think it's more a matter of that those who are in a position to do so are used enough with git-cli that they are happy with the status quo.
- couchand 6y ago
  It has been. There are numerous such projects; gitless comes to mind since somebody else brought it up in a comment here.
  - thrwyoilarticle 6y ago
    So the problem is solved and the OP blog shouldn't exist?
    - 3np 6y ago
      Your point being?

thaumasiotes 6y ago

> But that flexibility adds an extra cognitive burden when a newbie just wants to save a "backup snapshot of the repo". Simple needs have simple answers. git add . git commit -am '2020-11-17' Sure, you can ask "why are there two commands?", but this is not so much an issue of cognitive burden as of typing burden. If you only want one thing, you only have to know how to do one thing. If you don't want to know why the procedure does what it does, you don't have to.

Qwertious 6y ago
When you're writing into a text file and then save it, you don't have to manually select what lines or pages you're saving - you're saving all of it. This is the mental model 99% of newbies will have for something that basically pledges to save and sync each version of your files. Deviating from the user's mental model will create roadbumps and should not be done without a very strong rationale. Especially not for a feature that's fundamentally optional.
- tremon 6y ago
  When you're writing into a text file and then save it, you don't have to manually select what lines or pages you're saving - you're saving all of it So? When you're saving a file, you're also overwriting its entire contents. Good luck reverting back to the file before you saved it. There is no automatic model for "this change is worth tracking" and "this change is not important enough to annotate". That's the model that git is enabling, and it has nothing to do with the "save" button in an editor. If anything, it has more to do with the "track changes" feature in Word, but more powerful because it allows you to group multiple edits in the same change.
- thaumasiotes 6y ago
  > When you're writing into a text file and then save it, you don't have to manually select what lines or pages you're saving - you're saving all of it. I don't understand the point you're trying to make; this is just as true of the command I gave.
rsync 6y ago

hakre 6y ago

For snapshots use backups. Git is not a backup. For the questions, what's bad with quick help on SO? It's maybe less effective than reading the documentation that ships with git itself but for sure much more popular and less to read. Git truly is a command-line utility, little known is that it ships with more than one gui in the base package out of the box. handling the staging area with git gui for example is straight forward unless you have more than 5000 unstaged files, then the gui informs you about it's limit and mass handling is far easier on the command-line anyway.

grumple 6y ago

> Even though I grok git's mental model, I still can't answer the top-voted "git" questions on Stackoverflow without a cheat sheet This sounds like you just don't use or need those things much, which is fine if it works for you. Of the top 10, I can answer 9 of them without doing any research because I've used these commands a lot and they've become a part of my workflow. The one I'm missing? I've never renamed a git branch. If I needed to, I'd probably just do git branch --help or google it and figure it out in five seconds. You don't need to commit every command of the program to memory. Just like anything else in tech, knowing how to find the knowledge you need is good enough.

HourglassFR 6y ago

I feel the same way, I understand git pretty well but cannot for the life of me use the CLI. Fortunatly there are some pretty good GUI around, I personally use GitExtensions and find it suits my brain nicely. Its windows only though, not a problem for me since my work forces me to use Windows and I don't code at home but surely they are nice git GUI for Linux no ?