10 ms·

Ask HN: Do we need an easier Git?

Git is amazing and essential for my work. However, a vast majority of developers just use the clone-commit-push workflow and can get by. I've also taught CS to younger kids and seen students struggle to internalize the mental model of Git. The learning curve is steep for early devs. Is there merit in having a VCS that has a less steep learning curve or are the benefits of knowing a universal VCS too great (even if you end up using a small subset of the features)

nathias 5y ago
Git is the closest any software comes to perfection.
- lpcvoid 5y ago
  IMHO, that spot is reserved for sqlite.
- usr1106 5y ago
  The data model is. The choices made for naming and structuring the CLI certainly not.
  - nathias 5y ago
    you can make aliases and use extensions
ramesh31 5y ago
Yeah. Git is great software, but there's seriously no reason I should be typing multiple CLI commands over and over again as part of my workflow in the year 2022.
- usr1106 5y ago
  So what do you want to do? Pressing the mouse button over and over again? I don't claim the git CLI is always logical. But you seem to complain that there is one.
  - rgoulter 5y ago
    :) e.g. magit is keyboard focused, and a much nicer interface to git than the CLI.
- AndrewDucker 5y ago
  Use a GUI client. There are many of them.
- tehbeard 5y ago
  Ok, so I don't know your exact workflow as it could be some weird branch hopping and squashing and reflog breaking weirdness, but: 1. Most terminals have command history, so if you're really typing the same thing over & over & over & over... just use that? 2. Even if that's not the case, bash/batch/powershell scripts to automate things? 3. Most IDEs nowadays have pretty solid git integration so if you're wanting to click things, there's that.
- alblue 5y ago
  Then set up an alias to do it for you. https://alblue.bandlem.com/2011/04/git-tip-of-week-aliases.html https://alblue.bandlem.com/2011/04/git-tip-of-week-aliases.h...
- sys_64738 5y ago
  bash has a history search feature you can access via control-r.
billconan 5y ago
I do think git isn't user friendly. I came from perforce and also had a hard time building the mental model. Eventually I read the article about git's internals, and finally got the idea. What's most useful for me was the diagram of the three states (https://stackoverflow.com/questions/3689838/whats-the-difference-between-head-working-tree-and-index-in-git https://stackoverflow.com/questions/3689838/whats-the-differ...). some of the git's naming was also not intuitive for me, For example, calling the scratch area "index". I didn't seem to have to learn perforce, cvs or svn's internals to use them fluently. but I guess it's a bit difficult to change the current situation. git has become the most common choice. And once the mental model has built, it's not that difficult to use, admittedly I only use a few very common commands. you know the challenge won't be building the version control. for mass adoption, you need a github-like platform.
- TrianguloY 5y ago
  > some of the git's naming was also not intuitive for me For me this was (and is) the main source of "what is this and how do I use it" problems. Git is supposed to be an advanced tool to make snapshots of a folder, save them in a tree structure with multiple leaves, combine or even modify them, keep a copy remotely, etc. So, you are probably expecting to find a "save" command, an "upload/download", maybe a "combine snapshots", and for more advance tools an "edit history". But instead you have "commit", "push/pull", "merge" and "rebase". Those are less intuitive (specially for non English speakers) so you end using only the few ones someone told you to use. Once I realized what "fixup" was and how to use it I can't stop using it. Git model is no so complex, the naming is, so it's like learning a whole new language and it takes time.
  - jimnotgym 5y ago
    I think it is also true that many of us use github or similar with a PR workflow rather than the way Torvalds and the Linux core maintainers use git.
    - newswasboring 5y ago
      I don't think I know any other workflow but the PR based one.
mch82 5y ago
Maybe just an optional second cli for git that improves usability? If it takes off, switch it to default. Are there any examples of a cli tool with multiple, user selectable cli interfaces? Edit: to answer your question, there’s a lot of value to learning the standard industry scm tool.
- _ph_ 5y ago
  Yes there is. But there would be a tremendeous value to make the standard industry scm tool as user-friendly as possible. There are few tools where you would want to prevent user-errors more.
mikewarot 5y ago
I used the GIT GUI, and it seems easy enough for me, though I haven't pulled things out of repositories yet, just stage/commit | push to github What's needed is better documentation, nothing more.
kyriakos 5y ago
Basic git flow operations are straightforward. I taught a few graduates who had no prior vcs experience and they had no problem with day to day stuff. Because git is truly a powerful tool its ux becomes complicated once you need to do something beyond the simple operations.
- ldiracdelta 5y ago
  Have you used any other DVCS other than git? Bitkeeper ux us vastly better. Git ux is rough.
thisisonthetest 5y ago
this always makes me laugh: https://youtu.be/3mOVK0oSH2M https://youtu.be/3mOVK0oSH2M edit: start at 3:00 mins in
- ketanip 5y ago
  395K commands only needed for daily use, lol
- TrianguloY 5y ago
  When he entered the command and it started scrolling I was like "oh, I didn't know git had so many commands". Then it kept going, and going, and I started to feel fear. I think I'm going to use this when someone tells me "git is easy" Edit: I think the video was a joke, I don't find that list anywhere. Very funny anyways.
- alblue 5y ago
  This is the only git manpage you’ll ever need: https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/
- gurjeet 5y ago
  First 40 minutes are pure gold. He kept a straight face all through it, and made sure to not overdo it. An unsuspecting Git student would have no clue. Makes it very difficult to trust anything he says or does in the following segment.
- deleted 5y ago
  [deleted]
Gunax 5y ago
No matter how many times I do it, i have troubke squashing. Maybe I am just dumb .
- a_t48 5y ago
  git reset <parent> —soft; git commit -m squash The first command sets your current comment to parent, with any changes staged, the second commits it. I don’t mess with the interactive rebase. There’s a magic combination of this and the reflog that can preserve commit history, too.
gitgrump 5y ago
Respectfully, version control is not necessarily easy, and even with other versioning tools (they already exist, and some purport to be easier than git), you still have to think about what you're trying to do. I see this attitude a lot with new developers, and it's troubling. Of course git is hard; what part of computing _isn't_ hard? Git is a hell of a lot easier than, say, debugging a kernel panic, or solving a tricky race condition. If the vast majority of developers can't get by without learning anything beyond clone-commit-push, then I truly fear for our industry, because I am thoroughly average, and I have a pretty good idea of what git is up to when I run commands. Git might not have the best interface, and you could argue for different models, but some of this stuff just takes time and effort to learn. This is an important lesson for new developers to learn: some of this stuff is not, in fact, easy, and I don't where this expectation that it is comes from. It reflects a disturbing trend of learned helplessness I've noticed from newer developers. Computers are hard, but if you want to be the expert, you're going to have to figure it out. I don't think we need easier version control, I think we need developers who are willing to learn hard things.
02020202 5y ago
oneepic 5y ago
Overall IMO, Git is so good that if you have a problem with usability, it's better to work on a wrapper around Git than it is to change Git itself. Maybe a plain English tool that just lets you click through menus to dictate what you want to do. No Git lingo whatsoever. Very rough examples below: 1) "I want to save my progress". (combination of git add and git commit) 2) "I want to go back before my previous save." (`git revert` on your last commit) 3) "I want to upload my latest work." (git push) 4) "I want to pull in any new updates." (git pull) ...Et cetera. Stuff that's basic enough to satisfy some basic use cases. Then, for anything more complicated than this basic subset, users have to whip out the terminal. The balance between basic and complicated, and too little vs too much, might take time to figure out.
- usr1106 5y ago
  I fully agree. The challenge here might be if it's not a single user repo, how does the simple frontend deal with tricky cases introduced by other users?
  - oneepic 5y ago
    It probably wouldn't deal with it "well enough". Although, any errors or validation failures would point the user to use git commands to restore peace and order before using the tool again.
- martinvonz 5y ago
  The CLI could be simpler without making it less powerful. For example, "the index" should not be visible to the user, IMO. The usecases it enables can be achieved with a simpler CLI (like Mercurial does). Also, stashing could be automatic and rebase could also rebase descendant branches.
  - zibzab 5y ago
    > and rebase could also rebase descendant branches. Why?? This sounds like something that could break tons of workflows
bullen 5y ago
Since you should not be working in ways that create merge conflicts if you can avoid it I would say a simple distributed disk backup would be enough for 99% of programmers.
lifeplusplus 5y ago
git is worse than Linux in terms of UI
cicko 5y ago
Yes, it's called Mercurial.
- usr1106 5y ago
  So the answer would be, no it's Mercurial. I also used to like when I did not understand git well. After years of learning I mostly understand git and have mostly forgotten that Mercurial exists.
  - masklinn 5y ago
    > After years of learning I mostly understand git and have mostly forgotten that Mercurial exists. Meanwhile after years of learning I mostly understand git (and am pretty much the reference for colleagues) and I still wish more or less daily its UI wasn't so absolutely shit. Also revsets, good god of all the awful things in git's UI gitrevisions(7) ranks so, so high.
imdsm 5y ago
Personally, having used it for over a decade now, once you learn how it works, git is perfect. But it's not necessarily easy, sure. But then there are a lot of easy solutions out there that aren't very good. I'd say it's worth the investment to learn it, but I've seen so, so many developers refuse on the grounds that they simply don't want to. These are the folks who think it isn't good, the ones without experience.
bedobi 5y ago
Git is complex, which is fine. People take that to mean they need to learn and teach git in intricate detail, and use it in ways that are needlessly complex, which is dumb.
wyldfire 5y ago
The different flavors of processes using git are where I see significant differences in how hard it is to use. GitHub/GHE encourages pull requests and force-pushing a candidate branch. Gerrit encourages a staged-commit via "refs/for/$dest_branch". Projects like QEMU and the Linux kernel are much more decentralized and leverage requests to pull from dev repos and email patches ('git send-email'). All of these differences have some impact on how you use git locally and how easy or difficult it is to recover when you make a misstep. Subjectively I think that - the staging area is unnecessarily confusing (mercurial did this better imo), and the overloading of 'checkout' causes confusion too.
axegon_ 5y ago
No. I had to use mercurial at my old job and everyone in the company saw mercurial as an easy and efficient alternative to git - something which I could not comprehend. And truthfully after using the "easier" solution, I'd rather take the code, print it out on punch cards and compare them in order to create the adequate changes by taping the holes accordingly and feed the punch cards back into the computer. Now that I'm saying it and having looked at how mercurial works underneath, it's not far off, with the exception that mercurial creates copies of all punch cards and keeps stacking them on top of each other. I've never hated any version control as much and I've had to use svn in the past. Git operates on a strict and crazy stupid model without adding unnecessary features and advertising them as "flexibility" or "ergonomics". I've worked with juniors who've never used git in the past and in all instances it took them a day at most to figure out how it works.
- skinkestek 5y ago
  SVN isn't that bad at all. Perforce on the other hand when it is set up for pessimistic locking, that was interesting when I had to use it in a team setting and trying to work from home 14 years ago.
  - axegon_ 5y ago
    I mean... Credit where it's due: it certainly beats mercurial for me.
- imarg 5y ago
  We use mercurial at work. I actually like it very much (of course it might be because we follow a certain workflow). When I try to use git for personal projects (because everyone uses it and I'd like to learn it) and I really am struggling sometimes to get even the simplest workflow working as a single person. I can't even imagine how it would work when having multiple people work together.
  - axegon_ 5y ago
    That's the point: you have to follow a workflow to make it even remotely usable. And even so, they are hacky workarounds at best and generally mercurial feel like the product of "that's good enough". And in a more general sense mercurial feels like(and in fact historically is) the product of unsolicited help. The concepts of having separate actions for pull and update are ridiculous. The --new-branch option is equally stupid. Many basic features are missing and you have to resort to stuff such as plugins like evolve or whatever it was called(say rename an existing branch without causing the universe to implode on itself). Back-merging in mercurial makes no sense if you live with the basic assumption that you have one default/master/main or whatever you wanna call it branch. And truthfully, storing the entire history of your work as diffs is what I'd assume Gutenberg would have come up with - great for the 15-th century but sticks and stones by 21-st century standards. And a ton of other basic features are either missing or a complete hack - stashing, rebasing, update-index, submodules and all the things which personally as a git user, I take for granted.
Matthias247 5y ago
I don’t feel so. Beginners can learn a handful of commands to gets started. And once they started to contribute to a production project they anyway have to learn some additional advanced commands (mostly rebase on top of others changes and conflict resolution). Things beyond a rebase a rarely used by anyone, so most people can just avoid learning those or learn when necessary.
rotifer 5y ago
People might be interested in gitless [0], which purports to be "a Git-compatible version control system, that is easy to learn and use". It appears to be built on top of git, using a simplified conceptual model. I read about it in one of Adrian Colyer's "the morning paper" blog posts from 2016, "What’s wrong with Git? A conceptual design analysis" [1], which summarizes the paper that critiques git and describes gitless. (The link to the paper at the beginning of the post no longer works, but a commenter suggested this [2] instead.) I should point out that I've never used gitless, and I don't know whether it's still maintained, but if nothing else the critique itself is interesting. [0] https://gitless.com/ https://gitless.com/ [1] https://blog.acolyer.org/2016/10/24/whats-wrong-with-git-a-conceptual-design-analysis/ https://blog.acolyer.org/2016/10/24/whats-wrong-with-git-a-c... [2] https://web.archive.org/web/20131230194321/http://people.csail.mit.edu/sperezde/onward13.pdf https://web.archive.org/web/20131230194321/http://people.csa...
josefrichter 5y ago
It might be useful to be able to write git commands in more descriptive way for beginners. “Git add all new files”, “Git commit all files with message ‘foo’”, “Git show history of file ‘readme.txt’”, “Git restore previous version of file ‘readme.txt’”, etc.
pmontra 5y ago
My pain points with git are the detached head states (so puzzling) and basically everything that concern submodules (very brittle.) Anything about undoing commits, going back to a specific version of the code is less painful but I almost always have to google for it because that are not daily operations and I can't reliably remember them. Maybe that would be easier if I used a GUI instead of the command line. Anyway, a simplified git with only basic functionality and dead simple error messages AND part of the standard git distribution would be very useful. After all git does a lot of things but I'm using only a core 1% of it. Even after 10+ years I reliably know only the basic clone, add, pull, push, checkout, branch, commit, merge, rebase, log, diff commands. I have to google everything else, even how to track a remote branch. It's checkout -b but Gould I also fetch and pull it before? You got the idea. And it should be about files, directories and branches, the stuff developers reason about.
m4r35n357 5y ago
2143 5y ago
No. It was initially hard. But once I read through the excellent Git Book[1] things became very clear and intuitive. [1] https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2
musicmatze 5y ago
No, we need the power that git offers us for scaling workflows and contributions to large ecosystems. Software does not get less complex over time, but more complex - and we need a system to handle contributions to a complex system (read: large, distributed, multi-thousand developer/files codebase)! git is as simple as possible while being as powerful as possible. What we need is better education! Not only how git works, but also how clean and scaling development workflows work. I've seen too much "Lets just copy the code to the production environment"-workflows in my live already and I do not even have 3 full years of professional experience as a SW dev!
- DemocracyFTW 5y ago
  git is as simple as possible while being as powerful as possible This is far from being a foregone conclusion and would need a careful analysis to justify. FWIW Fossil manages to make do without Git's (insanely named) 'index' (what everyone calls the 'staging area').
lexicality 5y ago
In my experience doing mentorship, a lot of people are taught git in a super rushed way and tend to have the mindset of "here's this incredibly complicated program you will never understand, please learn these magic commands and hope you never get a merge conflict" which isn't particularly useful because they're now scared of their tools. We need to teach tools like git (and some editors!) as their own thing, completely separate to programming languages. Not "now we've written some code, let's put it in git" but "here's a tool called git, let's show how it works with some text files" Honestly - you spend 20 minutes with someone teaching them that git only stores diffs and how that actually works and they leave much more confident and willing to experiment on their own. A plain text TODO list is absolutely perfect for this, because a merge conflict between two steps on a numbered list is completely intuitive and resolvable. "I've got two 4)s now!" "What's the fix?" "I guess one needs to become 5)?" (The CLI and naming scheme is total garbage though - biggest hurdle for non-native English speakers IMO)
- bazzargh 5y ago
  Honestly - you spend 20 minutes with someone teaching them that git only stores diffs ...except that isn't what git stores (as loose objects); in fact it's one thing that distinguishes git from earlier tools. See eg https://medium.com/@paritosh90/understanding-git-internals-c389bc47faeb https://medium.com/@paritosh90/understanding-git-internals-c...
  - dkbrk 5y ago
    Yeah, I had this misconception for a while. I think it's useful to understand how git actually stores objects as blobs and trees, but the mental model of "commits are diffs" is still useful. Commands like git-cherry-pick really make the most sense when thought of in terms of diffs. Internally, for a command like that, git is taking the diff and applying it, anyway, so the model isn't really that inaccurate. I think the main place I've seen where the mental model of "commits are diffs" breaks down and actually leads to significant confusion and/or mistakes, is when the tree ends up in a weird state, such as in the middle of resolving a merge conflict. In that situation, it's important to keep in mind there's three separate tree-like things: the actual working tree; the index; and HEAD. And git status shows nothing more or less than the diff between the working tree and the index. I've gotten myself out of some confusing situations just by reminding myself of that and thinking things through very carefully.
darthrupert 5y ago
Mercurial was kinda that, and we mostly moved every mercurial repo to git.
CodeGlitch 5y ago
Having used SVN for a decade before we all moved to git, I have to say I've never noticed any improvement in our productivity. I.e. the limiting factor wasn't how well you can do a merge. In fact I've probably experienced more cock ups with git due to its increased complexity and insane naming scheme. I mean "checkout"... Completely inappropriate for what it does. Obviously with git you can work offline then sync later on, but that's not something you have to deal with in most organisations.
- zibzab 5y ago
  Hmmm, during your decade with subversion, did you ever try working with branches?
  - CodeGlitch 5y ago
    Of course - but we were still productive using SVN. The improvements in git didn't really give us a massive boost in productivity.
kmac_ 5y ago
Git it fine, maybe the naming could be better, but it's just something that anyone can get used to. The real issue is crazy workflows people tend to invent instead of using something common like Gitflow. But I have to admit that I prefer Mercurial, enforced immutable history makes everything easier. Also, I root for new alternatives like Pijul.
lormayna 5y ago
I think that mercurial (but also bzr) had a more understandable CLI and ux than git. Unfortunately git won the DCVS war.
charcircuit 5y ago
No, but something like magit should be provided out of the box with git. Git is pretty simple, but having a good user interface is essential.
henrydark 5y ago
Working with git for 5 years and SVN for 15 before that on teams ranging from 2 to 30 people, I think the problem of collaborative programming just isn't solved yet. It's not that git is special or especially hard. It's that distributed source control is a hard thing to understand, and no 20 minutes tutorial is going to solve that.
alkonaut 5y ago
There are definitely warts and sharp corners. Inconsistent cli api. The story for binaries with Git-LFS is still a mess (try using git over SSH with LFS or explain to a newcomer why it doesn’t work). Conflict resolution is still half stupid with very few easy ways of adding better more specialized merge drivers and deploying it over a company. Improvements like ReReRe and similar aren’t well integrated and enabled by default. Instead they are obscure additions so that you can get a less infuriating behavior. But only if you press the right buttons first. The worst aspect of it though is you can’t set it up to be properly centralized so that you truly bless a location which can keep things like branch name policies, distribute hooks to all employees etc. All that has to be built (poorly) on top, with ample opportunity to accidentally sidestep.
- zibzab 5y ago
  Technically, LFS isn't part of git and was added by a third party to solve a problem they had.
  - alkonaut 5y ago
    Yes. And it shows up as a massive hole in the feature set of git. Had it been a first class citizen together with other centralized workflow features, then obviously lfs would have worked over ssh. git is that it’s a tool written to solve distributed version control for Linux which is nearly the only project that’s effectively using distributed version control. Everyone else uses git for centralized version control. And it’a not a perfect fit.
deleted 5y ago
[deleted]
DarylZero 5y ago
No.
AnonC 5y ago
Gitless [1] has already been mentioned in another comment here. [2] That makes it easier to use git for those who are not as experienced or haven’t learned about the internals of git. For a different model (and other types of workflows), consider Fossil SCM. [3] Here’s a comparison of fossil with git, and what these tools are a good fit for. [4] I found fossil easier to understand, relatively speaking, and it seems simpler for personal use and for small teams. [1]: https://gitless.com/ https://gitless.com/ [2]: https://news.ycombinator.com/item?id=29757043 https://news.ycombinator.com/item?id=29757043 [3]: https://fossil-scm.org/ https://fossil-scm.org/ [4]: https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v...
StephenJGL 5y ago
The system has actual complexity. Actual complexity can't be abstracted away without reducing functionality. I think git has a poor/opaque command semantics outside the basic functions and the API could use some work. I think that a new review or "most used/useful commands" and an evaluation of whether the API to accomplish them can be simplified.
- sonotathrowaway 5y ago
  There are other projects attempting to tackle that complexity; namely https://pijul.org/ https://pijul.org/
mbfg 5y ago
I work with hundreds of developers with git, and yes 80% of them only know the basic workflow. The other 20% know a good bit more and can resolve any problem that occasionally comes up. I don't think it has hindered our development at all. People understand how the tool works for what they need, at the level they need. I'm good with that.
martinvonz 5y ago
There are tools out there that attempt to provide a simpler and/or more powerful CLI while letting you collaborate with others on existing Git repos. Gitless has already been mentioned here, but there's also my own tool (https://github.com/martinvonz/jj https://github.com/martinvonz/jj) and git-branchless (https://github.com/arxanas/git-branchless https://github.com/arxanas/git-branchless).
AnnoyedComment 5y ago
yoav 5y ago
I’ve used Git Tower for years because I dislike commandline. Git tower is a “simpler git” that makes many complex tasks safer and easier. But it’s on top of git so you have the full power of git if you do have to jump into the commandline. https://www.git-tower.com/mac https://www.git-tower.com/mac
softwaredoug 5y ago
Much of the complex parts of git have to do with rebasing and merging. But I remember that Pre-git this was hard too - the lack of features in VCS systems made it rather error prone. I recall manual 3-way merges and long conversations with colleagues about the right way to work through an SVN merge. Not to mention automated testing was less widespread, so it was harder to catch bugs. Git offers more features here. But the truth is the problem is just hard. Combining changes from multiple authors requires knowing both your tooling and code well.
oaf357 5y ago
Yes
maydup-nem 5y ago
> Git is amazing Let me take a wild guess here, bud, you are definitely an american, amiright? Git is shit, it just happens to be better than the competition coupled with the fact of its huge market share.

nathias 5y ago

Git is the closest any software comes to perfection.

lpcvoid 5y ago
IMHO, that spot is reserved for sqlite.
usr1106 5y ago
The data model is. The choices made for naming and structuring the CLI certainly not.
- nathias 5y ago
  you can make aliases and use extensions

ramesh31 5y ago

Yeah. Git is great software, but there's seriously no reason I should be typing multiple CLI commands over and over again as part of my workflow in the year 2022.

usr1106 5y ago
So what do you want to do? Pressing the mouse button over and over again? I don't claim the git CLI is always logical. But you seem to complain that there is one.
- rgoulter 5y ago
  :) e.g. magit is keyboard focused, and a much nicer interface to git than the CLI.
AndrewDucker 5y ago
Use a GUI client. There are many of them.
tehbeard 5y ago
Ok, so I don't know your exact workflow as it could be some weird branch hopping and squashing and reflog breaking weirdness, but: 1. Most terminals have command history, so if you're really typing the same thing over & over & over & over... just use that? 2. Even if that's not the case, bash/batch/powershell scripts to automate things? 3. Most IDEs nowadays have pretty solid git integration so if you're wanting to click things, there's that.
alblue 5y ago
Then set up an alias to do it for you. https://alblue.bandlem.com/2011/04/git-tip-of-week-aliases.html https://alblue.bandlem.com/2011/04/git-tip-of-week-aliases.h...
sys_64738 5y ago
bash has a history search feature you can access via control-r.

billconan 5y ago

I do think git isn't user friendly. I came from perforce and also had a hard time building the mental model. Eventually I read the article about git's internals, and finally got the idea. What's most useful for me was the diagram of the three states (https://stackoverflow.com/questions/3689838/whats-the-difference-between-head-working-tree-and-index-in-git https://stackoverflow.com/questions/3689838/whats-the-differ...). some of the git's naming was also not intuitive for me, For example, calling the scratch area "index". I didn't seem to have to learn perforce, cvs or svn's internals to use them fluently. but I guess it's a bit difficult to change the current situation. git has become the most common choice. And once the mental model has built, it's not that difficult to use, admittedly I only use a few very common commands. you know the challenge won't be building the version control. for mass adoption, you need a github-like platform.

TrianguloY 5y ago
> some of the git's naming was also not intuitive for me For me this was (and is) the main source of "what is this and how do I use it" problems. Git is supposed to be an advanced tool to make snapshots of a folder, save them in a tree structure with multiple leaves, combine or even modify them, keep a copy remotely, etc. So, you are probably expecting to find a "save" command, an "upload/download", maybe a "combine snapshots", and for more advance tools an "edit history". But instead you have "commit", "push/pull", "merge" and "rebase". Those are less intuitive (specially for non English speakers) so you end using only the few ones someone told you to use. Once I realized what "fixup" was and how to use it I can't stop using it. Git model is no so complex, the naming is, so it's like learning a whole new language and it takes time.
- jimnotgym 5y ago
  I think it is also true that many of us use github or similar with a PR workflow rather than the way Torvalds and the Linux core maintainers use git.
  - newswasboring 5y ago
    I don't think I know any other workflow but the PR based one.

mch82 5y ago

Maybe just an optional second cli for git that improves usability? If it takes off, switch it to default. Are there any examples of a cli tool with multiple, user selectable cli interfaces? Edit: to answer your question, there’s a lot of value to learning the standard industry scm tool.

_ph_ 5y ago
Yes there is. But there would be a tremendeous value to make the standard industry scm tool as user-friendly as possible. There are few tools where you would want to prevent user-errors more.

mikewarot 5y ago

I used the GIT GUI, and it seems easy enough for me, though I haven't pulled things out of repositories yet, just stage/commit | push to github What's needed is better documentation, nothing more.

kyriakos 5y ago

Basic git flow operations are straightforward. I taught a few graduates who had no prior vcs experience and they had no problem with day to day stuff. Because git is truly a powerful tool its ux becomes complicated once you need to do something beyond the simple operations.

ldiracdelta 5y ago
Have you used any other DVCS other than git? Bitkeeper ux us vastly better. Git ux is rough.

thisisonthetest 5y ago

this always makes me laugh: https://youtu.be/3mOVK0oSH2M https://youtu.be/3mOVK0oSH2M edit: start at 3:00 mins in

ketanip 5y ago
395K commands only needed for daily use, lol
TrianguloY 5y ago
When he entered the command and it started scrolling I was like "oh, I didn't know git had so many commands". Then it kept going, and going, and I started to feel fear. I think I'm going to use this when someone tells me "git is easy" Edit: I think the video was a joke, I don't find that list anywhere. Very funny anyways.
alblue 5y ago
This is the only git manpage you’ll ever need: https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/
gurjeet 5y ago
First 40 minutes are pure gold. He kept a straight face all through it, and made sure to not overdo it. An unsuspecting Git student would have no clue. Makes it very difficult to trust anything he says or does in the following segment.
deleted 5y ago
[deleted]

Gunax 5y ago

No matter how many times I do it, i have troubke squashing. Maybe I am just dumb .

a_t48 5y ago
git reset <parent> —soft; git commit -m squash The first command sets your current comment to parent, with any changes staged, the second commits it. I don’t mess with the interactive rebase. There’s a magic combination of this and the reflog that can preserve commit history, too.

gitgrump 5y ago

Respectfully, version control is not necessarily easy, and even with other versioning tools (they already exist, and some purport to be easier than git), you still have to think about what you're trying to do. I see this attitude a lot with new developers, and it's troubling. Of course git is hard; what part of computing _isn't_ hard? Git is a hell of a lot easier than, say, debugging a kernel panic, or solving a tricky race condition. If the vast majority of developers can't get by without learning anything beyond clone-commit-push, then I truly fear for our industry, because I am thoroughly average, and I have a pretty good idea of what git is up to when I run commands. Git might not have the best interface, and you could argue for different models, but some of this stuff just takes time and effort to learn. This is an important lesson for new developers to learn: some of this stuff is not, in fact, easy, and I don't where this expectation that it is comes from. It reflects a disturbing trend of learned helplessness I've noticed from newer developers. Computers are hard, but if you want to be the expert, you're going to have to figure it out. I don't think we need easier version control, I think we need developers who are willing to learn hard things.

02020202 5y ago

oneepic 5y ago

Overall IMO, Git is so good that if you have a problem with usability, it's better to work on a wrapper around Git than it is to change Git itself. Maybe a plain English tool that just lets you click through menus to dictate what you want to do. No Git lingo whatsoever. Very rough examples below: 1) "I want to save my progress". (combination of git add and git commit) 2) "I want to go back before my previous save." (`git revert` on your last commit) 3) "I want to upload my latest work." (git push) 4) "I want to pull in any new updates." (git pull) ...Et cetera. Stuff that's basic enough to satisfy some basic use cases. Then, for anything more complicated than this basic subset, users have to whip out the terminal. The balance between basic and complicated, and too little vs too much, might take time to figure out.

usr1106 5y ago
I fully agree. The challenge here might be if it's not a single user repo, how does the simple frontend deal with tricky cases introduced by other users?
- oneepic 5y ago
  It probably wouldn't deal with it "well enough". Although, any errors or validation failures would point the user to use git commands to restore peace and order before using the tool again.
martinvonz 5y ago
The CLI could be simpler without making it less powerful. For example, "the index" should not be visible to the user, IMO. The usecases it enables can be achieved with a simpler CLI (like Mercurial does). Also, stashing could be automatic and rebase could also rebase descendant branches.
- zibzab 5y ago
  > and rebase could also rebase descendant branches. Why?? This sounds like something that could break tons of workflows

bullen 5y ago

Since you should not be working in ways that create merge conflicts if you can avoid it I would say a simple distributed disk backup would be enough for 99% of programmers.

lifeplusplus 5y ago

git is worse than Linux in terms of UI

cicko 5y ago

Yes, it's called Mercurial.

usr1106 5y ago
So the answer would be, no it's Mercurial. I also used to like when I did not understand git well. After years of learning I mostly understand git and have mostly forgotten that Mercurial exists.
- masklinn 5y ago
  > After years of learning I mostly understand git and have mostly forgotten that Mercurial exists. Meanwhile after years of learning I mostly understand git (and am pretty much the reference for colleagues) and I still wish more or less daily its UI wasn't so absolutely shit. Also revsets, good god of all the awful things in git's UI gitrevisions(7) ranks so, so high.

imdsm 5y ago

Personally, having used it for over a decade now, once you learn how it works, git is perfect. But it's not necessarily easy, sure. But then there are a lot of easy solutions out there that aren't very good. I'd say it's worth the investment to learn it, but I've seen so, so many developers refuse on the grounds that they simply don't want to. These are the folks who think it isn't good, the ones without experience.

bedobi 5y ago

Git is complex, which is fine. People take that to mean they need to learn and teach git in intricate detail, and use it in ways that are needlessly complex, which is dumb.

wyldfire 5y ago

The different flavors of processes using git are where I see significant differences in how hard it is to use. GitHub/GHE encourages pull requests and force-pushing a candidate branch. Gerrit encourages a staged-commit via "refs/for/$dest_branch". Projects like QEMU and the Linux kernel are much more decentralized and leverage requests to pull from dev repos and email patches ('git send-email'). All of these differences have some impact on how you use git locally and how easy or difficult it is to recover when you make a misstep. Subjectively I think that - the staging area is unnecessarily confusing (mercurial did this better imo), and the overloading of 'checkout' causes confusion too.

axegon_ 5y ago

No. I had to use mercurial at my old job and everyone in the company saw mercurial as an easy and efficient alternative to git - something which I could not comprehend. And truthfully after using the "easier" solution, I'd rather take the code, print it out on punch cards and compare them in order to create the adequate changes by taping the holes accordingly and feed the punch cards back into the computer. Now that I'm saying it and having looked at how mercurial works underneath, it's not far off, with the exception that mercurial creates copies of all punch cards and keeps stacking them on top of each other. I've never hated any version control as much and I've had to use svn in the past. Git operates on a strict and crazy stupid model without adding unnecessary features and advertising them as "flexibility" or "ergonomics". I've worked with juniors who've never used git in the past and in all instances it took them a day at most to figure out how it works.

skinkestek 5y ago
SVN isn't that bad at all. Perforce on the other hand when it is set up for pessimistic locking, that was interesting when I had to use it in a team setting and trying to work from home 14 years ago.
- axegon_ 5y ago
  I mean... Credit where it's due: it certainly beats mercurial for me.
imarg 5y ago
We use mercurial at work. I actually like it very much (of course it might be because we follow a certain workflow). When I try to use git for personal projects (because everyone uses it and I'd like to learn it) and I really am struggling sometimes to get even the simplest workflow working as a single person. I can't even imagine how it would work when having multiple people work together.
- axegon_ 5y ago
  That's the point: you have to follow a workflow to make it even remotely usable. And even so, they are hacky workarounds at best and generally mercurial feel like the product of "that's good enough". And in a more general sense mercurial feels like(and in fact historically is) the product of unsolicited help. The concepts of having separate actions for pull and update are ridiculous. The --new-branch option is equally stupid. Many basic features are missing and you have to resort to stuff such as plugins like evolve or whatever it was called(say rename an existing branch without causing the universe to implode on itself). Back-merging in mercurial makes no sense if you live with the basic assumption that you have one default/master/main or whatever you wanna call it branch. And truthfully, storing the entire history of your work as diffs is what I'd assume Gutenberg would have come up with - great for the 15-th century but sticks and stones by 21-st century standards. And a ton of other basic features are either missing or a complete hack - stashing, rebasing, update-index, submodules and all the things which personally as a git user, I take for granted.

Matthias247 5y ago

I don’t feel so. Beginners can learn a handful of commands to gets started. And once they started to contribute to a production project they anyway have to learn some additional advanced commands (mostly rebase on top of others changes and conflict resolution). Things beyond a rebase a rarely used by anyone, so most people can just avoid learning those or learn when necessary.

rotifer 5y ago

People might be interested in gitless [0], which purports to be "a Git-compatible version control system, that is easy to learn and use". It appears to be built on top of git, using a simplified conceptual model. I read about it in one of Adrian Colyer's "the morning paper" blog posts from 2016, "What’s wrong with Git? A conceptual design analysis" [1], which summarizes the paper that critiques git and describes gitless. (The link to the paper at the beginning of the post no longer works, but a commenter suggested this [2] instead.) I should point out that I've never used gitless, and I don't know whether it's still maintained, but if nothing else the critique itself is interesting. [0] https://gitless.com/ https://gitless.com/ [1] https://blog.acolyer.org/2016/10/24/whats-wrong-with-git-a-conceptual-design-analysis/ https://blog.acolyer.org/2016/10/24/whats-wrong-with-git-a-c... [2] https://web.archive.org/web/20131230194321/http://people.csail.mit.edu/sperezde/onward13.pdf https://web.archive.org/web/20131230194321/http://people.csa...

josefrichter 5y ago

It might be useful to be able to write git commands in more descriptive way for beginners. “Git add all new files”, “Git commit all files with message ‘foo’”, “Git show history of file ‘readme.txt’”, “Git restore previous version of file ‘readme.txt’”, etc.

pmontra 5y ago

My pain points with git are the detached head states (so puzzling) and basically everything that concern submodules (very brittle.) Anything about undoing commits, going back to a specific version of the code is less painful but I almost always have to google for it because that are not daily operations and I can't reliably remember them. Maybe that would be easier if I used a GUI instead of the command line. Anyway, a simplified git with only basic functionality and dead simple error messages AND part of the standard git distribution would be very useful. After all git does a lot of things but I'm using only a core 1% of it. Even after 10+ years I reliably know only the basic clone, add, pull, push, checkout, branch, commit, merge, rebase, log, diff commands. I have to google everything else, even how to track a remote branch. It's checkout -b but Gould I also fetch and pull it before? You got the idea. And it should be about files, directories and branches, the stuff developers reason about.

m4r35n357 5y ago

2143 5y ago

No. It was initially hard. But once I read through the excellent Git Book[1] things became very clear and intuitive. [1] https://git-scm.com/book/en/v2 https://git-scm.com/book/en/v2

musicmatze 5y ago

No, we need the power that git offers us for scaling workflows and contributions to large ecosystems. Software does not get less complex over time, but more complex - and we need a system to handle contributions to a complex system (read: large, distributed, multi-thousand developer/files codebase)! git is as simple as possible while being as powerful as possible. What we need is better education! Not only how git works, but also how clean and scaling development workflows work. I've seen too much "Lets just copy the code to the production environment"-workflows in my live already and I do not even have 3 full years of professional experience as a SW dev!

DemocracyFTW 5y ago
git is as simple as possible while being as powerful as possible This is far from being a foregone conclusion and would need a careful analysis to justify. FWIW Fossil manages to make do without Git's (insanely named) 'index' (what everyone calls the 'staging area').

lexicality 5y ago

In my experience doing mentorship, a lot of people are taught git in a super rushed way and tend to have the mindset of "here's this incredibly complicated program you will never understand, please learn these magic commands and hope you never get a merge conflict" which isn't particularly useful because they're now scared of their tools. We need to teach tools like git (and some editors!) as their own thing, completely separate to programming languages. Not "now we've written some code, let's put it in git" but "here's a tool called git, let's show how it works with some text files" Honestly - you spend 20 minutes with someone teaching them that git only stores diffs and how that actually works and they leave much more confident and willing to experiment on their own. A plain text TODO list is absolutely perfect for this, because a merge conflict between two steps on a numbered list is completely intuitive and resolvable. "I've got two 4)s now!" "What's the fix?" "I guess one needs to become 5)?" (The CLI and naming scheme is total garbage though - biggest hurdle for non-native English speakers IMO)

bazzargh 5y ago
Honestly - you spend 20 minutes with someone teaching them that git only stores diffs ...except that isn't what git stores (as loose objects); in fact it's one thing that distinguishes git from earlier tools. See eg https://medium.com/@paritosh90/understanding-git-internals-c389bc47faeb https://medium.com/@paritosh90/understanding-git-internals-c...
- dkbrk 5y ago
  Yeah, I had this misconception for a while. I think it's useful to understand how git actually stores objects as blobs and trees, but the mental model of "commits are diffs" is still useful. Commands like git-cherry-pick really make the most sense when thought of in terms of diffs. Internally, for a command like that, git is taking the diff and applying it, anyway, so the model isn't really that inaccurate. I think the main place I've seen where the mental model of "commits are diffs" breaks down and actually leads to significant confusion and/or mistakes, is when the tree ends up in a weird state, such as in the middle of resolving a merge conflict. In that situation, it's important to keep in mind there's three separate tree-like things: the actual working tree; the index; and HEAD. And git status shows nothing more or less than the diff between the working tree and the index. I've gotten myself out of some confusing situations just by reminding myself of that and thinking things through very carefully.

darthrupert 5y ago

Mercurial was kinda that, and we mostly moved every mercurial repo to git.

CodeGlitch 5y ago

Having used SVN for a decade before we all moved to git, I have to say I've never noticed any improvement in our productivity. I.e. the limiting factor wasn't how well you can do a merge. In fact I've probably experienced more cock ups with git due to its increased complexity and insane naming scheme. I mean "checkout"... Completely inappropriate for what it does. Obviously with git you can work offline then sync later on, but that's not something you have to deal with in most organisations.

zibzab 5y ago
Hmmm, during your decade with subversion, did you ever try working with branches?
- CodeGlitch 5y ago
  Of course - but we were still productive using SVN. The improvements in git didn't really give us a massive boost in productivity.

kmac_ 5y ago

Git it fine, maybe the naming could be better, but it's just something that anyone can get used to. The real issue is crazy workflows people tend to invent instead of using something common like Gitflow. But I have to admit that I prefer Mercurial, enforced immutable history makes everything easier. Also, I root for new alternatives like Pijul.

lormayna 5y ago

I think that mercurial (but also bzr) had a more understandable CLI and ux than git. Unfortunately git won the DCVS war.

charcircuit 5y ago

No, but something like magit should be provided out of the box with git. Git is pretty simple, but having a good user interface is essential.

henrydark 5y ago

Working with git for 5 years and SVN for 15 before that on teams ranging from 2 to 30 people, I think the problem of collaborative programming just isn't solved yet. It's not that git is special or especially hard. It's that distributed source control is a hard thing to understand, and no 20 minutes tutorial is going to solve that.

alkonaut 5y ago

There are definitely warts and sharp corners. Inconsistent cli api. The story for binaries with Git-LFS is still a mess (try using git over SSH with LFS or explain to a newcomer why it doesn’t work). Conflict resolution is still half stupid with very few easy ways of adding better more specialized merge drivers and deploying it over a company. Improvements like ReReRe and similar aren’t well integrated and enabled by default. Instead they are obscure additions so that you can get a less infuriating behavior. But only if you press the right buttons first. The worst aspect of it though is you can’t set it up to be properly centralized so that you truly bless a location which can keep things like branch name policies, distribute hooks to all employees etc. All that has to be built (poorly) on top, with ample opportunity to accidentally sidestep.

zibzab 5y ago
Technically, LFS isn't part of git and was added by a third party to solve a problem they had.
- alkonaut 5y ago
  Yes. And it shows up as a massive hole in the feature set of git. Had it been a first class citizen together with other centralized workflow features, then obviously lfs would have worked over ssh. git is that it’s a tool written to solve distributed version control for Linux which is nearly the only project that’s effectively using distributed version control. Everyone else uses git for centralized version control. And it’a not a perfect fit.

deleted 5y ago

[deleted]

DarylZero 5y ago

No.

AnonC 5y ago

Gitless [1] has already been mentioned in another comment here. [2] That makes it easier to use git for those who are not as experienced or haven’t learned about the internals of git. For a different model (and other types of workflows), consider Fossil SCM. [3] Here’s a comparison of fossil with git, and what these tools are a good fit for. [4] I found fossil easier to understand, relatively speaking, and it seems simpler for personal use and for small teams. [1]: https://gitless.com/ https://gitless.com/ [2]: https://news.ycombinator.com/item?id=29757043 https://news.ycombinator.com/item?id=29757043 [3]: https://fossil-scm.org/ https://fossil-scm.org/ [4]: https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v...

StephenJGL 5y ago

The system has actual complexity. Actual complexity can't be abstracted away without reducing functionality. I think git has a poor/opaque command semantics outside the basic functions and the API could use some work. I think that a new review or "most used/useful commands" and an evaluation of whether the API to accomplish them can be simplified.

sonotathrowaway 5y ago
There are other projects attempting to tackle that complexity; namely https://pijul.org/ https://pijul.org/

mbfg 5y ago

I work with hundreds of developers with git, and yes 80% of them only know the basic workflow. The other 20% know a good bit more and can resolve any problem that occasionally comes up. I don't think it has hindered our development at all. People understand how the tool works for what they need, at the level they need. I'm good with that.

martinvonz 5y ago

There are tools out there that attempt to provide a simpler and/or more powerful CLI while letting you collaborate with others on existing Git repos. Gitless has already been mentioned here, but there's also my own tool (https://github.com/martinvonz/jj https://github.com/martinvonz/jj) and git-branchless (https://github.com/arxanas/git-branchless https://github.com/arxanas/git-branchless).

AnnoyedComment 5y ago

yoav 5y ago

I’ve used Git Tower for years because I dislike commandline. Git tower is a “simpler git” that makes many complex tasks safer and easier. But it’s on top of git so you have the full power of git if you do have to jump into the commandline. https://www.git-tower.com/mac https://www.git-tower.com/mac

softwaredoug 5y ago

Much of the complex parts of git have to do with rebasing and merging. But I remember that Pre-git this was hard too - the lack of features in VCS systems made it rather error prone. I recall manual 3-way merges and long conversations with colleagues about the right way to work through an SVN merge. Not to mention automated testing was less widespread, so it was harder to catch bugs. Git offers more features here. But the truth is the problem is just hard. Combining changes from multiple authors requires knowing both your tooling and code well.

oaf357 5y ago

Yes

maydup-nem 5y ago

> Git is amazing Let me take a wild guess here, bud, you are definitely an american, amiright? Git is shit, it just happens to be better than the competition coupled with the fact of its huge market share.