4 ms·

> Usually I accidentally committed to local master and then did a couple other things Create a new branch and check it out while you are on the last commit (gi

> Usually I accidentally committed to local master and then did a couple other things Create a new branch and check it out while you are on the last commit (git checkout -b my-branch), delete the master branch (git branch -D master), and pull it again (git pull -u origin master). You'll end up with a local branch with a bunch of commits that you can merge, rebase or cherrypick, depending on what you want. If you want to learn more about git in a practical way, there's an awesome book called Git Recipes.

brigandish 7y ago
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.
raducu 7y ago
Is there a reason for -D and not -d? Wouldn't -D also delete the remote branch if you accidentally pushed your changes?
- vvillena 7y ago
  "git branch -d" doesn't remove a branch if that means losing track of some local commits. "-D" doesn't check that. The "git branch" commands only operate on your local repo, they don't push any changes to remote repos and they don't pull commits from anywhere.
- WorldMaker 7y ago
  `-D` doesn't involve the remote at all (unless you are using something like the intentional remote:branch syntax which this example isn't). It is a force delete in that if there were commits locally in that branch and only in that branch it should still delete that branch. It should be unlikely you need that force because the first step was to branch everything as is, so it is safer to just use `-d`, but if the intention is to "blat" it from orbit anyway, `-D` is that.
Ntrails 7y ago
Deleting master is a thing that would _actually_ never have occurred to me! A neat trick That being an example that I remember from late last year, there are just sharp edges to git I end up catching myself on :)
- vvillena 7y ago
  The git "master" branch is just an example of 'convention over configuration': some commands use it as the default argument, just like "origin" is the default remote name. Nothing in git is special or sacred! :)

brigandish 7y ago

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.

raducu 7y ago

Is there a reason for -D and not -d? Wouldn't -D also delete the remote branch if you accidentally pushed your changes?

vvillena 7y ago
"git branch -d" doesn't remove a branch if that means losing track of some local commits. "-D" doesn't check that. The "git branch" commands only operate on your local repo, they don't push any changes to remote repos and they don't pull commits from anywhere.
WorldMaker 7y ago
`-D` doesn't involve the remote at all (unless you are using something like the intentional remote:branch syntax which this example isn't). It is a force delete in that if there were commits locally in that branch and only in that branch it should still delete that branch. It should be unlikely you need that force because the first step was to branch everything as is, so it is safer to just use `-d`, but if the intention is to "blat" it from orbit anyway, `-D` is that.

Ntrails 7y ago

Deleting master is a thing that would _actually_ never have occurred to me! A neat trick That being an example that I remember from late last year, there are just sharp edges to git I end up catching myself on :)

vvillena 7y ago
The git "master" branch is just an example of 'convention over configuration': some commands use it as the default argument, just like "origin" is the default remote name. Nothing in git is special or sacred! :)