7 ms·

I think part of the problem is that git, like other version control systems, does not enforce any particular way of working (workflow). When authors try to exp

by angdis 13y ago

I think part of the problem is that git, like other version control systems, does not enforce any particular way of working (workflow). When authors try to explain how to use git, they often have a very particular workflow in mind and don't necessarily describe exactly what that workflow is. This can cause major problems when somebody tries to apply advice to their own workflow. I like the graphical approach. It helps to conceptualize what is going on so that someone can apply it to their own situation.

tootie 13y ago
That's not it. Following any reasonable workflow still requires a set of arcane commands and flags that only make the slightest bit of sense if you know how git is implemented. I was able to use SVN successfully without ever knowing a thing about the implementation. I've generally had the same experience with HG and even CVS and VSS back in the day. Git adds sophistication over a prodcut like SVN, but adds vastly more complexity.
- dasil003 13y ago
  Conversely, SVNs data model remained opaque after years of daily use simply because it solves the problem at hand poorly and is not defined very well.
- DougWebb 13y ago
  I'm curious: did you use branches and labels in SVN? I've come across many svn repositories that don't use the trunk/branches/tags layout, and as a result the developers keep completely separate repositories for slightly different versions of their projects instead of creating branches. I've even seen new repositories created for each release version of the project. If you're using svn you need to understand the implementation to get why copies are cheap, so that you can understand how to use branching and tagging appropriately.
  - Pxtl 13y ago
    The problem is that with SVN, you can get in gradually. To start, the branchless approach still gets you a great service - obviously an incomplete one, but better than not having source control at all. And you can have leaders who are the only people who have to think about branching and merging and have people very gradually move into that role. Git seems to force you to dive straight into the deep-end, since everything is a branch, even your own local working folder.
    - jlgreco 13y ago
      Branches are fundamentally little more than text files in .git/refs/heads that contain the sha of a commit object. Don't let the idea of a branch frighten you, there isn't much complexity behind the idea.
  - hibbelig 13y ago
    Well, I know _that_ copies are cheap in svn, but I have no idea _why_. Yet I hope that I grok branches and tags.
- jeltz 13y ago
  I used SVN for years without understanding it and that caused me to get weird merge errors I never managed to figure out. Git on the other hand I understood after a few weeks of using it. Since I failed to understand SVN after years of use I would say it is more complex.
  - jlgreco 13y ago
    That is where I am at. Being able to use something for years while never actually understanding it is not a desirable position to be in, and really does not equate to any meaningful sense of simplicity. It particularly is not something that developers should strive for in a system built for developers.
- StavrosK 13y ago
  It's that its porcelain is a clusterfuck. The staging area is a hack that greatly convolutes the UI, and it would have been better if it were left out and you just had a way to cherry-pick what you want to commit at commit time (if it wasn't everything). There's no symmetry in commands. The opposite of "git commit" is "git reset --soft HEAD^", not "git uncommit". "git reset" is three commands in one. I could go on and on. git was designed as a data model and then a series of slapdash commands that enabled manipulation of that data model. It wasn't designed from the end-user perspective backwards, and this really, really shows.
  - leephillips 13y ago
    I might not [EDIT: in fact, was not: see reply below] be appreciating the way that the staging area convolutes the UI for you, but you can pretend it doesn't exist by always just doing commit -a. And, if you want to "cherry-pick what you want to commit at commit time", well, that's what the staging area is for, isn't it?
    - StavrosK 13y ago
      Pretending it doesn't exist won't unconvolute the UI. I'm talking about things like "git checkout -- <file>", and "Git reset" which could just be one command if they didn't have to manage getting things in and out of the staging area. I much prefer bzr's porcelain, it's much better designed and more sane.
  - jlgreco 13y ago
    You're basically railing against orthogonality. I don't think anybody disagrees that some flags could be made more consistent, but creating a separate git-uncommit when that functionality is fundamentally encompassed by the purpose of the third invocation of git-reset is a mistake. If you make a specific case for 'git reset --hard/--soft HEAD^' then you would either be left without the more general (and more useful) 'git reset --hard/--soft <commit>', or you would have a situation where you have to use 'uncommit' to (for example) re-commit something, or you would be left with a git-uncommit command and still have git-reset for related operations. Why would any of that be better? You could split the third invocation of git-reset off into its own command, but honestly I don't see the utility in doing that.
- nilkn 13y ago
  I had to use svn in college for some projects and we frequently ran into terrible merge problems that we simply couldn't figure out because we didn't know what was actually going on behind the scenes. git is more complex on the surface, but I really find it to be so much simpler when you end up in real nontrivial use cases, especially when something goes wrong. I would agree that the commands are sometimes too memorization-intensive, but I've never been in a situation with git, even as a beginner, that I couldn't figure out and resolve relatively easily, especially with all the online resources available. I can't say the same for svn. Maybe I was just an idiot when using svn, but if I was an idiot there, I don't see why I wouldn't be an idiot with git as well unless there was just something fundamentally more useable and flexible and understandable about git.
- Perseids 13y ago
  The underlying data structures do matter, even with mercurial. One workflow I immensely appreciate with Git is locally committing some series of messy changesets and commit messages and then afterwards, when I have finished the feature, tidying everything up by rewriting the history (git rebase -i) before I push my commits. When I tried the same approach with mercurial I found that rewriting the history is not reasonably supported by mercurial. They use these append-only data structures that sound nice, because they assure stability (no already written data is ever in danger because files are only appended) and fit with the general concept of commit->pull->merge. But when you want to change the commit history you clash with the append-only concept. The Histedit extension which is meant to provide this feature has warnings all over the place that what I do is dangerous and might result in data loss with changeset backups written to locations in the working tree. It's horrible compared to Git. Now don't misunderstand me, Git has a lot of problems UI wise (for example I still don't really grasp what is going on with detached heads). But I find the fundamental design choices more sound than with any other VCS that I have tried.
  - develop7 13y ago
    Your rebase-based workflow is easily achievable with Mercurial. And there's even --outgoing switch in histedit. > Histedit extension which is meant to provide this feature has warnings all over the place Ignore them — you do know, what are you doing, right? > changeset backups written to locations in the working tree That's not true. Backups are written to .hg/strip-backup directory, which isn't tracked.
    - Perseids 13y ago
      > Ignore them — you do know, what are you doing, right? No, I don't :). I heavily rely on my CVS to never loose any data and to be able to go back to a previous state whenever I need to. This works great with Git's reflog. > That's not true. Backups are written to .hg/strip-backup directory, which isn't tracked. I stand corrected then. Maybe I'm mixing that up with amend or revert? I last used mercurial 9 months ago, but believe to remember there was some command that left .orig files lying around and that if you applied a history rewrite command several times those backups were overwritten with the new backups and you weren't able to come back all the way.

by angdis 13y ago

tootie 13y ago

That's not it. Following any reasonable workflow still requires a set of arcane commands and flags that only make the slightest bit of sense if you know how git is implemented. I was able to use SVN successfully without ever knowing a thing about the implementation. I've generally had the same experience with HG and even CVS and VSS back in the day. Git adds sophistication over a prodcut like SVN, but adds vastly more complexity.

dasil003 13y ago
Conversely, SVNs data model remained opaque after years of daily use simply because it solves the problem at hand poorly and is not defined very well.
DougWebb 13y ago
I'm curious: did you use branches and labels in SVN? I've come across many svn repositories that don't use the trunk/branches/tags layout, and as a result the developers keep completely separate repositories for slightly different versions of their projects instead of creating branches. I've even seen new repositories created for each release version of the project. If you're using svn you need to understand the implementation to get why copies are cheap, so that you can understand how to use branching and tagging appropriately.
- Pxtl 13y ago
  The problem is that with SVN, you can get in gradually. To start, the branchless approach still gets you a great service - obviously an incomplete one, but better than not having source control at all. And you can have leaders who are the only people who have to think about branching and merging and have people very gradually move into that role. Git seems to force you to dive straight into the deep-end, since everything is a branch, even your own local working folder.
  - jlgreco 13y ago
    Branches are fundamentally little more than text files in .git/refs/heads that contain the sha of a commit object. Don't let the idea of a branch frighten you, there isn't much complexity behind the idea.
- hibbelig 13y ago
  Well, I know _that_ copies are cheap in svn, but I have no idea _why_. Yet I hope that I grok branches and tags.
jeltz 13y ago
I used SVN for years without understanding it and that caused me to get weird merge errors I never managed to figure out. Git on the other hand I understood after a few weeks of using it. Since I failed to understand SVN after years of use I would say it is more complex.
- jlgreco 13y ago
  That is where I am at. Being able to use something for years while never actually understanding it is not a desirable position to be in, and really does not equate to any meaningful sense of simplicity. It particularly is not something that developers should strive for in a system built for developers.
StavrosK 13y ago
It's that its porcelain is a clusterfuck. The staging area is a hack that greatly convolutes the UI, and it would have been better if it were left out and you just had a way to cherry-pick what you want to commit at commit time (if it wasn't everything). There's no symmetry in commands. The opposite of "git commit" is "git reset --soft HEAD^", not "git uncommit". "git reset" is three commands in one. I could go on and on. git was designed as a data model and then a series of slapdash commands that enabled manipulation of that data model. It wasn't designed from the end-user perspective backwards, and this really, really shows.
- leephillips 13y ago
  I might not [EDIT: in fact, was not: see reply below] be appreciating the way that the staging area convolutes the UI for you, but you can pretend it doesn't exist by always just doing commit -a. And, if you want to "cherry-pick what you want to commit at commit time", well, that's what the staging area is for, isn't it?
  - StavrosK 13y ago
    Pretending it doesn't exist won't unconvolute the UI. I'm talking about things like "git checkout -- <file>", and "Git reset" which could just be one command if they didn't have to manage getting things in and out of the staging area. I much prefer bzr's porcelain, it's much better designed and more sane.
- jlgreco 13y ago
  You're basically railing against orthogonality. I don't think anybody disagrees that some flags could be made more consistent, but creating a separate git-uncommit when that functionality is fundamentally encompassed by the purpose of the third invocation of git-reset is a mistake. If you make a specific case for 'git reset --hard/--soft HEAD^' then you would either be left without the more general (and more useful) 'git reset --hard/--soft <commit>', or you would have a situation where you have to use 'uncommit' to (for example) re-commit something, or you would be left with a git-uncommit command and still have git-reset for related operations. Why would any of that be better? You could split the third invocation of git-reset off into its own command, but honestly I don't see the utility in doing that.
nilkn 13y ago
I had to use svn in college for some projects and we frequently ran into terrible merge problems that we simply couldn't figure out because we didn't know what was actually going on behind the scenes. git is more complex on the surface, but I really find it to be so much simpler when you end up in real nontrivial use cases, especially when something goes wrong. I would agree that the commands are sometimes too memorization-intensive, but I've never been in a situation with git, even as a beginner, that I couldn't figure out and resolve relatively easily, especially with all the online resources available. I can't say the same for svn. Maybe I was just an idiot when using svn, but if I was an idiot there, I don't see why I wouldn't be an idiot with git as well unless there was just something fundamentally more useable and flexible and understandable about git.
Perseids 13y ago
The underlying data structures do matter, even with mercurial. One workflow I immensely appreciate with Git is locally committing some series of messy changesets and commit messages and then afterwards, when I have finished the feature, tidying everything up by rewriting the history (git rebase -i) before I push my commits. When I tried the same approach with mercurial I found that rewriting the history is not reasonably supported by mercurial. They use these append-only data structures that sound nice, because they assure stability (no already written data is ever in danger because files are only appended) and fit with the general concept of commit->pull->merge. But when you want to change the commit history you clash with the append-only concept. The Histedit extension which is meant to provide this feature has warnings all over the place that what I do is dangerous and might result in data loss with changeset backups written to locations in the working tree. It's horrible compared to Git. Now don't misunderstand me, Git has a lot of problems UI wise (for example I still don't really grasp what is going on with detached heads). But I find the fundamental design choices more sound than with any other VCS that I have tried.
- develop7 13y ago
  Your rebase-based workflow is easily achievable with Mercurial. And there's even --outgoing switch in histedit. > Histedit extension which is meant to provide this feature has warnings all over the place Ignore them — you do know, what are you doing, right? > changeset backups written to locations in the working tree That's not true. Backups are written to .hg/strip-backup directory, which isn't tracked.
  - Perseids 13y ago
    > Ignore them — you do know, what are you doing, right? No, I don't :). I heavily rely on my CVS to never loose any data and to be able to go back to a previous state whenever I need to. This works great with Git's reflog. > That's not true. Backups are written to .hg/strip-backup directory, which isn't tracked. I stand corrected then. Maybe I'm mixing that up with amend or revert? I last used mercurial 9 months ago, but believe to remember there was some command that left .orig files lying around and that if you applied a history rewrite command several times those backups were overwritten with the new backups and you weren't able to come back all the way.