61–70 of 83 posts
The thing that gets me every time is the git sub-commands which have multiple orthogonal uses, without so much as a command line flag to differentiate them. git reset abc # unstage file `abc` git reset xyz # switch to commit `xyz` or: git checkout mybranch # switch to branch `mybranch` git checkout myfile # remove any local changes to `myfile` since the last commit --- Maybe this would work great in a typed language…
All fair points. So what can we actually do about it?
Use something better? Like Fossil? I find Fossil way, way more friendly and useful for individual users and teams. http://fossil-scm.org/
All fair points. So what can we actually do about it?
It's open source; make suggestions, contributions, have a voice.
I've been using git for 7 years now. Never used anything else for version control (besides visual source safe which I try to forget). Never felt the need or desire to try anything else.
Earlier quoted context omitted.
Is hg easier to use? Or any other DVCS not created by such a bad UX practitioner?
I was a major user of hg from 2007-2012, before I succumbed to network effects. The UX of hg was more intuitive for users coming from SVN and CVS.
I second this. Trying to go from SVN to git left me confused and frustrated, while I found it much easier to switch to hg. Once I had been using hg for a while, I found that I had absorbed enough of the difficult/confusing stuff that switching to git was relatively painless.
Things I hate about Git (stevebennett.me) 31 points by rbanffy 2 hours ago Could do with 2012 in the title: Posted by steveko on February 24, 2012
Once you get the essence of git (objects, graph, commits as snapshots etc) everything becomes really easy. You don't need to memorize all command just need to understand some basic concepts. And some points about the article. Git is a framework actually, you need some workflow to use it in a team. So git requires a lot of discipline from all team members. You can't just "commit" as in subversion, you must understand…
https://git-man-page-generator.lokaltog.net/
It describes advanced features like `git-govern-origin` and `git-organize-head` [0].
[0]. https://git-man-page-generator.lokaltog.net/#26463b871524ca4...
This leads to the UX that was initially planned becoming unwieldy. I think most organizations default to no-merge, rebase-and-commit-only mode, with master acting as the central branch to push to.
Hence what git needs to improve it's UX to a newcomer is to help define a repository to be in a "no-merge", and then help translate user's following actions:
git init
git commitchanges
git push
git pull
I'm convinced the entire workflow related to merges, and non-centralized features are what cause UX confusion for a new user.
Earlier quoted context omitted.
Is hg easier to use? Or any other DVCS not created by such a bad UX practitioner?
Hg is easier to use for mainly 2 reasons: 1. The UI is more consistent ie. the "update" command only does 1 thing updates your working directory to a specified state. 2. It doesn't have a pre-commit staging "index" like Git (or it at least doesn't expose it to the user. So workflow is a bit for straightforward ie. you don't need to constantly "add" files before you commit, it automatically does it for you.
Plus, while the UX of git is not intuitive, especially from SVN, if you want to bypass staging and just use it like SVN, you can "git commit -a". Like svn, if you have new, untracked files, you can "git add -A; git commit". This is also trivial to alias.
I'm working with a small team that uses CVS and I'm I'm in charge of recommending more modern version control software. I've been learning git since it seems to be the new standard, but after reading this, I don't think we have the time it will take to learn it. Is there another open source vcs that would be a more natural upgrade to CVS?