9 ms·

That is not easier than "blat and re-clone" so I think you're proving their point.

munmaek 7y ago
If you’re just going to blat and reclone, then you may as well use a folder system instead of git. I see no reason git needs to be changed in order to cater to people who refuse to read basic documentation or learn from their mistakes.
- mannykannot 7y ago
  I did not read brigandish's comment as advocacy of 'blat and reclone', I took it to be a comment on git's awkwardness. I have considerable sympathy for the RTFM reply, but I do not think it is the last word that shuts down any question of usability. What seems clear to me is that there are a lot of people using git who probably should not be. In many cases, they do not have a choice, but I also suspect that many of the organizations that have chosen git do not have the issues that it is optimized for.
- brigandish 7y ago
  > I see no reason git needs to be changed in order to cater to people who refuse to read basic documentation or learn from their mistakes. In my opinion, solving problems and making improvements involves reducing complexity, not defending it. Many people, including myself, have read the Git docs and learnt about the underlying data structures etc etc and still we can make the claim that it could be better, in numerous ways. Calling everyone feckless won't invalidate that.
  - munmaek 7y ago
    > we can make the claim that it could be better I’m not disputing this. Of course git isn’t perfect. What I’m against is changing git to cater to people who can’t read the manual and make basic mistakes.
    - antris 7y ago
      > What I’m against is changing git to cater to people who can’t read the manual and make basic mistakes. Why? Isn't software that doesn't require reading a manual and doesn't let the user make irreversible mistakes considered good design?
      - munmaek 7y ago
        Not if it means reducing capabilities of the program in order to add bumper guards. I can’t think of any software that handles a complex program that doesn’t have a manual, documentation like a manual, or a learning curve. Git is a tool for developers, not casual users who want typical apps. Again, you wouldn’t make an argument like this for a tool used by a plumber or a mechanic. If a tool succinctly handles a problem, good! But using tools is part of the profession; they have learning curves. Most issues with git are PEBKAC issues because people refuse to spend 10 minutes of their life reading about a tool they may use for hundreds or thousands of hours. I wouldn’t want to cater to those kinds of people.
        brigandish 7y ago
        What can Git do that Fossil or Mercurial can't?
        antris 7y ago
        Software can cater to multiple types of uses at the same time. You can have a learn-as-you-go experience while keeping your powerful tools that enable more fine-tuned or complex tasks. Easy-to-use vs. powerful is a false dichotomy. About the plumbing/mechanic analogy, I totally would make the same case! Hammers and wrenches don't require a manual and can be used for very complex tasks, and that's exactly what makes them so well designed and popular. Few people want their hammer to have more features, and if they do, they still want to keep the good old hammer ready, because it's so easy and simple to use. Especially calling out PEBKAC (Problem Exists Between Keyboard And Computer) - while even most of the expert git users, including the author himself say the interface could at least be made much better - makes me really suspicious that you simply like feeling superior to other people because you know something they don't, and you don't want to lose your "edge" if suddenly everyone can use version control without resorting to manuals.
vvillena 7y ago
Recloning means redoing your work on top of a potentially different codebase. The approach I described is how you "blat and reclone" using git instead of the filesystem, and it has the clear advantage of keeping everything in the same repo. You can then mix all the code together in whatever way you prefer. Git is a very flexible tool that allows for individual local workflows independent of how teams collaborate. Finding a personal workflow that works for you is a little investment that pays huge dividends for a long time. Git is a 15 year old tool that is expected to live for 10-30 years more at the very least. I encourage everyone to learn enough Git to not be afraid of it.

If you’re just going to blat and reclone, then you may as well use a folder system instead of git. I see no reason git needs to be changed in order to cater to people who refuse to read basic documentation or learn from their mistakes.

mannykannot 7y ago
I did not read brigandish's comment as advocacy of 'blat and reclone', I took it to be a comment on git's awkwardness. I have considerable sympathy for the RTFM reply, but I do not think it is the last word that shuts down any question of usability. What seems clear to me is that there are a lot of people using git who probably should not be. In many cases, they do not have a choice, but I also suspect that many of the organizations that have chosen git do not have the issues that it is optimized for.
brigandish 7y ago
> I see no reason git needs to be changed in order to cater to people who refuse to read basic documentation or learn from their mistakes. In my opinion, solving problems and making improvements involves reducing complexity, not defending it. Many people, including myself, have read the Git docs and learnt about the underlying data structures etc etc and still we can make the claim that it could be better, in numerous ways. Calling everyone feckless won't invalidate that.
- munmaek 7y ago
  > we can make the claim that it could be better I’m not disputing this. Of course git isn’t perfect. What I’m against is changing git to cater to people who can’t read the manual and make basic mistakes.
  - antris 7y ago
    > What I’m against is changing git to cater to people who can’t read the manual and make basic mistakes. Why? Isn't software that doesn't require reading a manual and doesn't let the user make irreversible mistakes considered good design?
    - munmaek 7y ago
      Not if it means reducing capabilities of the program in order to add bumper guards. I can’t think of any software that handles a complex program that doesn’t have a manual, documentation like a manual, or a learning curve. Git is a tool for developers, not casual users who want typical apps. Again, you wouldn’t make an argument like this for a tool used by a plumber or a mechanic. If a tool succinctly handles a problem, good! But using tools is part of the profession; they have learning curves. Most issues with git are PEBKAC issues because people refuse to spend 10 minutes of their life reading about a tool they may use for hundreds or thousands of hours. I wouldn’t want to cater to those kinds of people.
      - brigandish 7y ago
        What can Git do that Fossil or Mercurial can't?
      - antris 7y ago
        Software can cater to multiple types of uses at the same time. You can have a learn-as-you-go experience while keeping your powerful tools that enable more fine-tuned or complex tasks. Easy-to-use vs. powerful is a false dichotomy. About the plumbing/mechanic analogy, I totally would make the same case! Hammers and wrenches don't require a manual and can be used for very complex tasks, and that's exactly what makes them so well designed and popular. Few people want their hammer to have more features, and if they do, they still want to keep the good old hammer ready, because it's so easy and simple to use. Especially calling out PEBKAC (Problem Exists Between Keyboard And Computer) - while even most of the expert git users, including the author himself say the interface could at least be made much better - makes me really suspicious that you simply like feeling superior to other people because you know something they don't, and you don't want to lose your "edge" if suddenly everyone can use version control without resorting to manuals.

vvillena 7y ago

Recloning means redoing your work on top of a potentially different codebase. The approach I described is how you "blat and reclone" using git instead of the filesystem, and it has the clear advantage of keeping everything in the same repo. You can then mix all the code together in whatever way you prefer. Git is a very flexible tool that allows for individual local workflows independent of how teams collaborate. Finding a personal workflow that works for you is a little investment that pays huge dividends for a long time. Git is a 15 year old tool that is expected to live for 10-30 years more at the very least. I encourage everyone to learn enough Git to not be afraid of it.