3 ms·

They do make a lot of sense if you understand the underlying model (read gittutorial(7), gittutorial-2(7), and gitcore-tutorial(7)). Its UI could be better, but

They do make a lot of sense if you understand the underlying model (read gittutorial(7), gittutorial-2(7), and gitcore-tutorial(7)). Its UI could be better, but it's good enough and some tools just require training to use effectively.

User23 6y ago
It takes about an hour to read and understand that documentation and I highly recommend doing so. And once you do git becomes far more intuitive. The key concepts to understand are commits and refs. To a first approximation a branch is just a variable ref and a tag is a constant ref. A commit is a node in a generally sparse upside down tree and refs are pointers to said nodes. Once one realizes that then pretty much everything makes sense. For example the difference between rebase and merge is how they affect the structure of the commit tree.
- cnst 6y ago
  To add to that: learn how to use git-reflog. It's the most fantastic thing ever, let's you have a complete control over the local revision history to undo anything you want. I think Git is a real pleasure to use. Personally, with git-reflog, I think it's really difficult to mess up in a git repo (but, of course, if there's a will, there's a way). I've worked with SVN on several repos and projects, and it's the VCS I like the least. It's not intuitive at all, less shell-scriptable than CVS (how do you `cvs diff -r1.{1,2} file.c` in SVN?), less portable and takes more time to setup (e.g., effectively less UNIX). I think the ViewVC interface is also one of the worst out of any other option out there, be that CVSweb or gitweb, both of which have a better usability, in my opinion. SVN repository is also a 100% monolith, unlike CVS and even unlike Git (in Git, you can't ignore individual files like in CVS, but you still can ignore unrelated branches for a checkout, for example, without the need to renumber the whole thing, which is a requirement in SVN if you want to get rid of any branch). Basically, my personal opinion, is that the monolithic and inflexible SVN is just broken by design for any distributed and large project the size of a BSD. It's still puzzling to me why it was chosen over Git back in 2008, the same year that DragonFly did select Git as replacement for CVS. If anything, with DragonFly project being smaller, they had less of a need for Git than did FreeBSD.
- mmis1000 6y ago
  It is actually even simpler, a commit is a complete file tree with some message, other metadata and hashs of its parent commits. A commit without parent is the initial commit. A merge commit is simply a commit that has more than one parent commits. In reality, you can put whatever content on whatever commits as long as these rule don't break. The git is just the program that you used to merge the file tree, while you can disgrace with it with '--no-commit' and modified the merged file tree as you want.
- kergonath 6y ago
  You’re right, but missing the point. I know what commits and refs are. Every time someone says that the syntax is unnecessarily complicated, a lot of well-intentioned people react as if we did not know a thing about git. Some commands and manipulations are just very unintuitive and cumbersome.
  - User23 6y ago
    I wonder if that's actually true. Nothing is stopping you or anyone else from releasing an entirely compatible new set of porcelain commands, and yet nobody has done so and gotten any traction. Also what do you mean by intuitive? Intuitive to someone who is trying to keep using CVS but with git, or intuitive to someone who actually understands the Git data model? Since it sounds like you're in the latter group, what would your ideal porcelain look like?
kergonath 6y ago
I know the model. And I have read the documentation, as well as the git book, and now a fair number of Stack Overflow (and similar websites) pages. I actually use git fairly often, and for day-to-day use it’s fine. The problem is for more complex manipulations I do maybe every 6 months. The logic behind difference between commands and options is really not obvious, and some commands are very asymmetric (doing something can be simple and take one command; undoing it might take a completely different command with several options and complex references). The concept is great and it works very well; the UI is terrible.

User23 6y ago

It takes about an hour to read and understand that documentation and I highly recommend doing so. And once you do git becomes far more intuitive. The key concepts to understand are commits and refs. To a first approximation a branch is just a variable ref and a tag is a constant ref. A commit is a node in a generally sparse upside down tree and refs are pointers to said nodes. Once one realizes that then pretty much everything makes sense. For example the difference between rebase and merge is how they affect the structure of the commit tree.

cnst 6y ago
To add to that: learn how to use git-reflog. It's the most fantastic thing ever, let's you have a complete control over the local revision history to undo anything you want. I think Git is a real pleasure to use. Personally, with git-reflog, I think it's really difficult to mess up in a git repo (but, of course, if there's a will, there's a way). I've worked with SVN on several repos and projects, and it's the VCS I like the least. It's not intuitive at all, less shell-scriptable than CVS (how do you `cvs diff -r1.{1,2} file.c` in SVN?), less portable and takes more time to setup (e.g., effectively less UNIX). I think the ViewVC interface is also one of the worst out of any other option out there, be that CVSweb or gitweb, both of which have a better usability, in my opinion. SVN repository is also a 100% monolith, unlike CVS and even unlike Git (in Git, you can't ignore individual files like in CVS, but you still can ignore unrelated branches for a checkout, for example, without the need to renumber the whole thing, which is a requirement in SVN if you want to get rid of any branch). Basically, my personal opinion, is that the monolithic and inflexible SVN is just broken by design for any distributed and large project the size of a BSD. It's still puzzling to me why it was chosen over Git back in 2008, the same year that DragonFly did select Git as replacement for CVS. If anything, with DragonFly project being smaller, they had less of a need for Git than did FreeBSD.
mmis1000 6y ago
It is actually even simpler, a commit is a complete file tree with some message, other metadata and hashs of its parent commits. A commit without parent is the initial commit. A merge commit is simply a commit that has more than one parent commits. In reality, you can put whatever content on whatever commits as long as these rule don't break. The git is just the program that you used to merge the file tree, while you can disgrace with it with '--no-commit' and modified the merged file tree as you want.
kergonath 6y ago
You’re right, but missing the point. I know what commits and refs are. Every time someone says that the syntax is unnecessarily complicated, a lot of well-intentioned people react as if we did not know a thing about git. Some commands and manipulations are just very unintuitive and cumbersome.
- User23 6y ago
  I wonder if that's actually true. Nothing is stopping you or anyone else from releasing an entirely compatible new set of porcelain commands, and yet nobody has done so and gotten any traction. Also what do you mean by intuitive? Intuitive to someone who is trying to keep using CVS but with git, or intuitive to someone who actually understands the Git data model? Since it sounds like you're in the latter group, what would your ideal porcelain look like?

kergonath 6y ago

I know the model. And I have read the documentation, as well as the git book, and now a fair number of Stack Overflow (and similar websites) pages. I actually use git fairly often, and for day-to-day use it’s fine. The problem is for more complex manipulations I do maybe every 6 months. The logic behind difference between commands and options is really not obvious, and some commands are very asymmetric (doing something can be simple and take one command; undoing it might take a completely different command with several options and complex references). The concept is great and it works very well; the UI is terrible.