4 ms·

This is the classic "I want to use a new, more powerful tool, but I'm going to rely on concepts from the old tool and not bother to learn the new one." If you'r

by asolove 13y ago

This is the classic "I want to use a new, more powerful tool, but I'm going to rely on concepts from the old tool and not bother to learn the new one." If you're using git in this way, you should just use svn. You'll be missing out on the power of git, but you already are, and at least your tool will match your mental model of it.

phillmv 13y ago
That's a false dichotomy. Matter of fact is there is no right way to use git, because the way you use git is going to change according to your organization size and complexity. The Linux kernel is a very different animal than your average rinky-dink hobby project, which is different from your ten-dev consultancy. Matter of fact is: the git UX is awful and it punishes everyone who doesn't have have a high level understanding of how the underlying persistence model works.
- jheriko 13y ago
  > Matter of fact is: the git UX is awful and it punishes everyone who doesn't have have a high level understanding of how the underlying persistence model works. that is very true imo. reverting a merge once its pushed is a real headache in git compared to mercurial and its caused me problems often enough at critical moments that i simply refuse to use git it can solve my problem but even 'experts' who like to tell me how to do it and how 'easy' it is seem to miss crucial details - the documentation is a little lacking in that area too... in short i can learn how to do it with hg from no previous knowledge so quickly that i can not worry about forgetting it. with git the overhead for learning how to perform this one task is far too great - mainly down to ultra configurability and what imo are extremely poor choices of defaults.
- korzun 13y ago
  No matter how large or small your organization is, you don't work on upstream branch unless you don't understand the whole concept of git. Even for my personal projects I have my own work and merge to upstream master when I'm ready with a major feature set. Sure you can work directly on master for small stuff, but for anything else good luck buddy. Humans make errors and it will catch up to you.
  - Guvante 13y ago
    > you don't work on upstream branch unless you don't understand the whole concept of git As painful as it is, it is unavoidable in oddball situations. The problem is everyone leaves it as "don't do that" rather than "don't do that, but if you do, here is how to fix it". Normally trudging through the doco would get you to the fix, but back to problem #1.
- sethrin 13y ago
  > Matter of fact is: the git UX is awful and it punishes everyone who doesn't have have a high level understanding of how the underlying persistence model works. I believe this is true, but reading through a description of how the underlying persistence model works was for me a revelatory experience. This was presented together with a description of the precise problem git was designed to solve in the O'Reilly book, Version Control with Git. It seemed to be a problem solved in every particular -- an exact solution, that rarest of all things. I did struggle with git before I read about it, which is why I picked up the book in the first place. Since then I have convinced myself that any failures with git are due to my own deficiencies and not its, but my tasks with git are far from exotic; I rarely encounter any difficulties. The value in the software is not so much the UX, which I consider acceptable (at least with aliases), but in the underlying data model. For me, it is a tool of daily use, and so the knowledge required to use it is a trivial investment. If we were discussing something other than a command-line tool, I think I might be more amenable to the argument that a simpler UX is a better one. With the CLI though, you pretty much need to know what you're doing before you attempt to do it, and any problems with the process are rarely considered UX issues.
  - johnbm 13y ago
    Isn't it a problem then that Git does not expose or visualize its internal model in any comprehensible way to its end users? That and the lack of instant undo seem ridiculous for a program designed to manage change.
    - to3m 13y ago
      gitk --all is excellent for this. I didn't really fully understand what git rebase was for until I worked through a few tests on my repository, refreshing the GUI after each command I typed.
    - sethrin 13y ago
      It has a steep learning curve. It is not optimized for novices. In my opinion, it does exactly what it should do internally, while I consider other tools to be deficient in some respects. In the common case, undo is provided by git commit --amend. For anything more complicated, I don't think that there is an explanation or GUI which could be considered "intuitive". I've used gitk and git-gui, and a variety of other visual interfaces before Reading the Figurative Manual, and while I'll be the first to cry my own ignorance, I have not found any of them to give much information about even the available options. What is cherry-picking? What about reverse cherry-picking? When would you want to use either? It's not impossible to design a user interface which would translate all of git's graph manipulations into a simple visual system. However, its current textual interface is extremely flexible, and it exposes a very useful scripting interface. It is a tool that rewards knowledge and experience, like emacs or vi(m). Which is not to say that it's necessarily a good value proposition to you, but it is (imo) a good time investment. One of these days I need to invest in vim too :(
- enraged_camel 13y ago
  >>Matter of fact is: the git UX is awful and it punishes everyone who doesn't have have a high level understanding of how the underlying persistence model works. I learned Git very recently, and I agree. It took me a while to grasp the basics because they just are not intuitive unless you understand how everything works under the hood.
pjc50 13y ago
Actively choosing a version control system is a rare decision; the vast majority of the time you have to use whatever the project leader (OSS) / company wants. If a project is on github I can't exactly choose to use svn. This has led to me using some truly terrible version control systems, of which the worst was Cadence DesignSync. When using this system I wrote a rant detailing it (which is very offtopic for this thread but might be amusing): - by default, a "checkout" contains symlinks to (non-writable) files, not the files themselves. - this means that files can change under you. I suppose it saves a bit of disk space. - want to edit a file? Mandatory locking! - yes, that's right, mandatory locking is used instead of merges. No built in merging at all. - In theory that avoids conflicts. In practice, what happens is: people take their own copy of the file, edit it, get the lock, write their edited version in. - because it's hand-merged or unmerged, we've frequently lost changes and had to reapply them. - towards the end of the project, finding out that the file you needed was locked by someone in a different timezone who'd gone home was getting really, really infuriating. - to top it all, it's very, very slow. This article from 2002 describes someone else having the same experience and building a "just use Perforce" frontend: http://eetimes.com/electronics-news/4153780/Irritation-prompts-engineer-to-write-open-source-tool http://eetimes.com/electronics-news/4153780/Irritation-promp...
- steveklabnik 13y ago
  > If a project is on github I can't exactly choose to use svn. https://github.com/blog/1178-collaborating-on-github-with-subversion https://github.com/blog/1178-collaborating-on-github-with-su...

by asolove 13y ago

phillmv 13y ago

That's a false dichotomy. Matter of fact is there is no right way to use git, because the way you use git is going to change according to your organization size and complexity. The Linux kernel is a very different animal than your average rinky-dink hobby project, which is different from your ten-dev consultancy. Matter of fact is: the git UX is awful and it punishes everyone who doesn't have have a high level understanding of how the underlying persistence model works.

jheriko 13y ago
> Matter of fact is: the git UX is awful and it punishes everyone who doesn't have have a high level understanding of how the underlying persistence model works. that is very true imo. reverting a merge once its pushed is a real headache in git compared to mercurial and its caused me problems often enough at critical moments that i simply refuse to use git it can solve my problem but even 'experts' who like to tell me how to do it and how 'easy' it is seem to miss crucial details - the documentation is a little lacking in that area too... in short i can learn how to do it with hg from no previous knowledge so quickly that i can not worry about forgetting it. with git the overhead for learning how to perform this one task is far too great - mainly down to ultra configurability and what imo are extremely poor choices of defaults.
korzun 13y ago
No matter how large or small your organization is, you don't work on upstream branch unless you don't understand the whole concept of git. Even for my personal projects I have my own work and merge to upstream master when I'm ready with a major feature set. Sure you can work directly on master for small stuff, but for anything else good luck buddy. Humans make errors and it will catch up to you.
- Guvante 13y ago
  > you don't work on upstream branch unless you don't understand the whole concept of git As painful as it is, it is unavoidable in oddball situations. The problem is everyone leaves it as "don't do that" rather than "don't do that, but if you do, here is how to fix it". Normally trudging through the doco would get you to the fix, but back to problem #1.
sethrin 13y ago
> Matter of fact is: the git UX is awful and it punishes everyone who doesn't have have a high level understanding of how the underlying persistence model works. I believe this is true, but reading through a description of how the underlying persistence model works was for me a revelatory experience. This was presented together with a description of the precise problem git was designed to solve in the O'Reilly book, Version Control with Git. It seemed to be a problem solved in every particular -- an exact solution, that rarest of all things. I did struggle with git before I read about it, which is why I picked up the book in the first place. Since then I have convinced myself that any failures with git are due to my own deficiencies and not its, but my tasks with git are far from exotic; I rarely encounter any difficulties. The value in the software is not so much the UX, which I consider acceptable (at least with aliases), but in the underlying data model. For me, it is a tool of daily use, and so the knowledge required to use it is a trivial investment. If we were discussing something other than a command-line tool, I think I might be more amenable to the argument that a simpler UX is a better one. With the CLI though, you pretty much need to know what you're doing before you attempt to do it, and any problems with the process are rarely considered UX issues.
- johnbm 13y ago
  Isn't it a problem then that Git does not expose or visualize its internal model in any comprehensible way to its end users? That and the lack of instant undo seem ridiculous for a program designed to manage change.
  - to3m 13y ago
    gitk --all is excellent for this. I didn't really fully understand what git rebase was for until I worked through a few tests on my repository, refreshing the GUI after each command I typed.
  - sethrin 13y ago
    It has a steep learning curve. It is not optimized for novices. In my opinion, it does exactly what it should do internally, while I consider other tools to be deficient in some respects. In the common case, undo is provided by git commit --amend. For anything more complicated, I don't think that there is an explanation or GUI which could be considered "intuitive". I've used gitk and git-gui, and a variety of other visual interfaces before Reading the Figurative Manual, and while I'll be the first to cry my own ignorance, I have not found any of them to give much information about even the available options. What is cherry-picking? What about reverse cherry-picking? When would you want to use either? It's not impossible to design a user interface which would translate all of git's graph manipulations into a simple visual system. However, its current textual interface is extremely flexible, and it exposes a very useful scripting interface. It is a tool that rewards knowledge and experience, like emacs or vi(m). Which is not to say that it's necessarily a good value proposition to you, but it is (imo) a good time investment. One of these days I need to invest in vim too :(
enraged_camel 13y ago
>>Matter of fact is: the git UX is awful and it punishes everyone who doesn't have have a high level understanding of how the underlying persistence model works. I learned Git very recently, and I agree. It took me a while to grasp the basics because they just are not intuitive unless you understand how everything works under the hood.

pjc50 13y ago

Actively choosing a version control system is a rare decision; the vast majority of the time you have to use whatever the project leader (OSS) / company wants. If a project is on github I can't exactly choose to use svn. This has led to me using some truly terrible version control systems, of which the worst was Cadence DesignSync. When using this system I wrote a rant detailing it (which is very offtopic for this thread but might be amusing): - by default, a "checkout" contains symlinks to (non-writable) files, not the files themselves. - this means that files can change under you. I suppose it saves a bit of disk space. - want to edit a file? Mandatory locking! - yes, that's right, mandatory locking is used instead of merges. No built in merging at all. - In theory that avoids conflicts. In practice, what happens is: people take their own copy of the file, edit it, get the lock, write their edited version in. - because it's hand-merged or unmerged, we've frequently lost changes and had to reapply them. - towards the end of the project, finding out that the file you needed was locked by someone in a different timezone who'd gone home was getting really, really infuriating. - to top it all, it's very, very slow. This article from 2002 describes someone else having the same experience and building a "just use Perforce" frontend: http://eetimes.com/electronics-news/4153780/Irritation-prompts-engineer-to-write-open-source-tool http://eetimes.com/electronics-news/4153780/Irritation-promp...

steveklabnik 13y ago
> If a project is on github I can't exactly choose to use svn. https://github.com/blog/1178-collaborating-on-github-with-subversion https://github.com/blog/1178-collaborating-on-github-with-su...