4 ms·

I use git all the time and prefer it for all types of workflow as a VCS, but this idea that git is perfect and it's your own fault for not learning it properly

I use git all the time and prefer it for all types of workflow as a VCS, but this idea that git is perfect and it's your own fault for not learning it properly is ridiculous. UX/UI in programs is important. I believe that git has one of the worst, most inconsistent UX's of all time. You can see this by the fractured commands. Quick examples: 'git reset' vs. 'git revert' and sometime 'git checkout' 'git checkout' vs. 'git clone' vs. 'git pull' vs. 'git fetch' vs. 'git cherrypick' 'git rebase' vs. 'git merge' vs. 'git merge --squash' Each one of these performs actions on a repo giving you immense power and control to do specific actions, but it's horrible UX. It's very easy to end up in a detached HEAD state, or have accidentally rebased a repo so it's out of alignment with a remote, leaving you with the trouble of dealing with that. It's crap experience, and all I want to do is code. What does it say when resolving these problems the easiest thing is to just reclone the remote repo? I commend this project for trying to apply some sanity to the entire thing.

zajd 10y ago
> What does it say when resolving these problems the easiest thing is to just reclone the remote repo? It says the git works really well because the CLI offers a simple way to "undo" any mistakes you've made. The real reason people struggle with git, and I've seen this in many other programs/places is that they rely on discoverability and just randomly try commands until they work. Git's simplicity is it's downfall. You don't see people wrapping Angular2 in other frameworks to deal with the warts. There's a reason people are told to look at man pages all the time, the command line is not the place to play "discoverability". There's already plenty of suggestions and help features built into the tool. > It's crap experience, and all I want to do is code. - every engineer when first experiencing version control
- bluejekyll 10y ago
  > It says the git works really well because the CLI offers a simple way to "undo" any mistakes you've made. This let's the design off the hook to easily. Yes, on the one hand this is a great feature, but on the other, you are deleting and restarting your workspace. It's not a great UX, it's just a simple workaround for a bad one. > - every engineer when first experiencing version control no, wrong. git is unique in the amount of information that you need to know just to get started with it.
  - zajd 10y ago
    > no, wrong. git is unique in the amount of information that you need to know just to get started with it. Have you ever worked with a different VCS? How is setting up subversion or CVS any more difficult than going git init git add . git commit -m "initial commit" Yes, truly a monumental barrier to entry to get started. http://vasc.ri.cmu.edu/old_help/Archiving/Cvs/cvs_tutorial.texinfo.html http://vasc.ri.cmu.edu/old_help/Archiving/Cvs/cvs_tutorial.t... If you think git is unique in the amount of information it takes to get started... I pray you work on nothing that even broaches complex.
    - bluejekyll 10y ago
      > Have you ever worked with a different VCS? Yes, I've worked with RCS, CVS, SVN, SourceSafe, Perforce and some others, though know them less well. Git is bar none the best of all (of which I've had experience) the VCS' out there. I would pick it over anything else. The issues I'm pointing out are not because I don't use it, don't understand it, or don't appreciate it. I just believe that it's too complex. If git was literally just the set of commands you listed, that would be great. As a single user experience it's hardly ever an issue. But that doesn't mean that it can't be better! And that's why I like this gitless project (and some of the other similar ones out there), it's trying to create a decent experience that will scale. Also, your example is about creating a new git repo, I find this to be much more rare than getting involved in an already built and multi-member team, which may have all sorts of rules about proper merges or rebases, and such.
      - zajd 10y ago
        It can be though. That's like saying Linux would be better if they only gave you ls, cat and nano because vi, sed and xargs were too complicated. There is nothing about gitless that provides a decent experience (compared to git) and certainly nothing about gitless that has anything to do with operating at "scale". The truth is commands like filter-branch, rebase, cherry-pick, etc. which are notoriously difficult to use... you don't even have to use them. I'm not saying the git experience can't get better, but the way forward is to modify the existing tools and contribute to the project, not make git wrapper number 84 that does nothing special.
fail2fail2ban 10y ago
Agree. There needs to be a higher level git command interface for those of us who appreciate git's power but would prefer to just get common stuff done without worrying if we just messed up months of work and have to unwind and fix the screwed up code base. git reminds me of C, super powerful and super easy to mess up.
arielb1 10y ago
How are `git reset` and `git revert` related? How are `git fetch` and `git cherrypick` related?
- bluejekyll 10y ago
  In my mind you use many of those commands to perform actions in the repo or locally which are related. For example: 'git reset HEAD~1' is something I use often, it is vaguely like 'git revert <last-hash>'. Therefore I see them as providing similar functions semantically, but not literally. 'git fetch' and 'git cherrypick' are again similar in my mind where one is pulling changes from a remote, while the other pulls a set of changes from one branch into another locally. This is not as good an example though, but I do think they have slightly overlapping concepts.

zajd 10y ago

> What does it say when resolving these problems the easiest thing is to just reclone the remote repo? It says the git works really well because the CLI offers a simple way to "undo" any mistakes you've made. The real reason people struggle with git, and I've seen this in many other programs/places is that they rely on discoverability and just randomly try commands until they work. Git's simplicity is it's downfall. You don't see people wrapping Angular2 in other frameworks to deal with the warts. There's a reason people are told to look at man pages all the time, the command line is not the place to play "discoverability". There's already plenty of suggestions and help features built into the tool. > It's crap experience, and all I want to do is code. - every engineer when first experiencing version control

bluejekyll 10y ago
> It says the git works really well because the CLI offers a simple way to "undo" any mistakes you've made. This let's the design off the hook to easily. Yes, on the one hand this is a great feature, but on the other, you are deleting and restarting your workspace. It's not a great UX, it's just a simple workaround for a bad one. > - every engineer when first experiencing version control no, wrong. git is unique in the amount of information that you need to know just to get started with it.
- zajd 10y ago
  > no, wrong. git is unique in the amount of information that you need to know just to get started with it. Have you ever worked with a different VCS? How is setting up subversion or CVS any more difficult than going git init git add . git commit -m "initial commit" Yes, truly a monumental barrier to entry to get started. http://vasc.ri.cmu.edu/old_help/Archiving/Cvs/cvs_tutorial.texinfo.html http://vasc.ri.cmu.edu/old_help/Archiving/Cvs/cvs_tutorial.t... If you think git is unique in the amount of information it takes to get started... I pray you work on nothing that even broaches complex.
  - bluejekyll 10y ago
    > Have you ever worked with a different VCS? Yes, I've worked with RCS, CVS, SVN, SourceSafe, Perforce and some others, though know them less well. Git is bar none the best of all (of which I've had experience) the VCS' out there. I would pick it over anything else. The issues I'm pointing out are not because I don't use it, don't understand it, or don't appreciate it. I just believe that it's too complex. If git was literally just the set of commands you listed, that would be great. As a single user experience it's hardly ever an issue. But that doesn't mean that it can't be better! And that's why I like this gitless project (and some of the other similar ones out there), it's trying to create a decent experience that will scale. Also, your example is about creating a new git repo, I find this to be much more rare than getting involved in an already built and multi-member team, which may have all sorts of rules about proper merges or rebases, and such.
    - zajd 10y ago
      It can be though. That's like saying Linux would be better if they only gave you ls, cat and nano because vi, sed and xargs were too complicated. There is nothing about gitless that provides a decent experience (compared to git) and certainly nothing about gitless that has anything to do with operating at "scale". The truth is commands like filter-branch, rebase, cherry-pick, etc. which are notoriously difficult to use... you don't even have to use them. I'm not saying the git experience can't get better, but the way forward is to modify the existing tools and contribute to the project, not make git wrapper number 84 that does nothing special.

fail2fail2ban 10y ago

Agree. There needs to be a higher level git command interface for those of us who appreciate git's power but would prefer to just get common stuff done without worrying if we just messed up months of work and have to unwind and fix the screwed up code base. git reminds me of C, super powerful and super easy to mess up.

arielb1 10y ago

How are `git reset` and `git revert` related? How are `git fetch` and `git cherrypick` related?

bluejekyll 10y ago
In my mind you use many of those commands to perform actions in the repo or locally which are related. For example: 'git reset HEAD~1' is something I use often, it is vaguely like 'git revert <last-hash>'. Therefore I see them as providing similar functions semantically, but not literally. 'git fetch' and 'git cherrypick' are again similar in my mind where one is pulling changes from a remote, while the other pulls a set of changes from one branch into another locally. This is not as good an example though, but I do think they have slightly overlapping concepts.