3 ms·

Are you really shocked that someone would make a backup before doing something they are unsure of? Personally, I git clone a fresh copy to do any advanced stuf

Are you really shocked that someone would make a backup before doing something they are unsure of? Personally, I git clone a fresh copy to do any advanced stuff in, and sometimes an extra just as a backup. Though that's not really much different than copying the folder. Especially if he has uncommitted files like IDE settings and whatnot he doesn't want to fix if things go really bad.

globular-toast 5y ago
> Are you really shocked that someone would make a backup before doing something they are unsure of? No, but I'm shocked git is so misunderstood that this would be considered a time to do this. Keeping a backup of previous versions is git's raison d'être. If you can't trust git to do this, how can you trust "cp" to make a copy of a file? I would love to get a genuine answer to my question: what do you think git is for and why do you use it? This would help me enormously to understand where you are coming from.
- erwincoumans 5y ago
  Git is a popular distributed versioning tool, but some commands have obscure syntax that is easy to get wrong, leading you into a mess that becomes a time drain. Creating a zip file of a git root folder takes seconds, and can get you out of the mess in seconds, rather than spending minutes or hours to undo some mess. If you can foresee git getting into a mess (and I can, after > 10 years of git experience), you can just take that backup to save time 'just in case' your git repo gets into that mess again. Changing the git commit history (for example because you made a commit under the wrong name/email address) in particular can cause huge headaches. Doing a git merge with tons of changes (think of clang-format white space changes in combination with various other commits) is another one. This is not about the specific cases where your git repo can become a mess, but more about having a simple safety mechanism to always get you out of the mess.
- nkozyra 5y ago
  > If you can't trust git to do this, how can you trust "cp" to make a copy of a file? I would love to get a genuine answer to my question: what do you think git is for and why do you use it? This would help me enormously to understand where you are coming from. All of us - at some point - were new to git and coming from other VCS systems meant there was a relatively steep learning curve. I also understand git fear - some of the stuff is a little arcane, and organizations are often very dogmatic and loud about their usage and approaches to git. It leads to a lot of gatekeeping. Do we rebase here? Do we never rebase? Linear history? Rebase feature branches or merge directly into main? It makes the fear of the tool that much stronger. `cp`, on the other hand, is pretty straightforward. There are no local approaches to using it, there's no real `cp` expert in-house at most places. It does what it says on the box without a lot of frills or options. git is a complex tool. It becomes easier the longer you use it, like most things, but it can be very intimidating to new or intermediate users.
  - globular-toast 5y ago
    > All of us - at some point - were new to git and coming from other VCS systems meant there was a relatively steep learning curve. He's not new to it. He says he's been using it for over 10 years!
- jcranmer 5y ago
  > No, but I'm shocked git is so misunderstood that this would be considered a time to do this. You shouldn't be. As you say, you shouldn't need to do this, but the fact that so many people do feel the need to do this speaks to poor UI design on git's part. There are, I think, two main reasons why people feel the need to do this. The first is that git makes it really easy to rewrite history, without really offering much in the way of safety rails. You have but to be burned by this once to lose all trust in git whatsoever. And this is something where there are safer ways to rewrite history: Mercurial's concept of phases or changeset evolution is easily far better than git in this regard. Even exporting the excised revisions as a revset ("strip-backup") is far easier for me to undo than having to go into git reflog (especially because I don't need to race any `git gc` command--note that git is the only VCS that feels the need to have a garbage collector!). The second issue is that git has a lot of different places where state can be hiding, and it quickly becomes unclear which of the various places a command is affecting. Is this going to update my working directory, the most recent commit, the staging area, or multiple of those copies? If I'm in the middle of an interactive rebase, do I need to `git commit` or `git commit --amend` or some other command to properly update "the" commit? Maybe if you're fluent in git, it's all obvious, but if you're not fluent, it's way too easy to accidentally do the wrong thing. And looking up git documentation doesn't help--it's the only tool I regularly use where reading the documentation actively leaves me more confused than before I consulted it.
  - globular-toast 5y ago
    > The first is that git makes it really easy to rewrite history, without really offering much in the way of safety rails It does, I just think they are not obvious enough because people haven't read an article like the one posted here. Git is an append-only data store. You can't lose anything as long as you have committed it. Rebasing does rewrite history, but it doesn't delete the old history. It's still there. The reflog links to it. The old remote tracking branch links to it. You could even leave a tag there to link to it. There are many ways to get back.
- throwhauser 5y ago
  Combining a small repertoire of git commands and this type of brute-force backup allows people to use git without having to learning all the details of its inner workings (or at least not having to keep that knowledge in everyday short-term memory.) If a small repertoire of git commands covers 95% of what a person needs git for, and recovering from backup covers the remaining 5%, why spend time and effort "git-ifying" that last 5%?
- housecarpenter 5y ago
  It's entirely possible to trust something to work one way (e.g. keep a trivially restorable backup of previous state) when you do one thing with it and not trust it to do the same thing when you do another thing with it (especially if it's something you do infrequently or have never done before). The advantage of cp compared to git is that it only does one thing (more or less), so you don't have the potential for "doing things you're unsure of" in the same way as git.
- dec0dedab0de 5y ago
  Backups and version history are not the same thing. Especially when you're messing with the version history. I make copies when I'm using git-filter-repo, or BFG. But even rebase is a destructive action that would be nice to have a safety net for. In the real world people have a ton of untracked files for their development environment, and uncommitted changes, but need an update from a coworkers branch that has a conflict with development, and a different conflict with your local changes. This can leave you in a weird state pretty quickly, and merge conflicts are a pain, especially if the conflicts are in a part of the code you're not very familiar with. Personally, I go full cowboy and work my way through it, but I am not surprised in the least when I hear that people make a backup so they can quickly restore. One benefit of copying a directory instead of using git is that it will copy all of your untracked files, and uncommitted changes as is. Another benefit is that it works the same no matter what tooling you're using. I believe that some legacy code at my company is still on SVN and source safe. I also use open source projects that are developed with mercurial, bazaar, and fossil. If I were going to work on any of them, I would definitely be making backups the standard way instead of trusting my ability to use the tool properly.

globular-toast 5y ago

> Are you really shocked that someone would make a backup before doing something they are unsure of? No, but I'm shocked git is so misunderstood that this would be considered a time to do this. Keeping a backup of previous versions is git's raison d'être. If you can't trust git to do this, how can you trust "cp" to make a copy of a file? I would love to get a genuine answer to my question: what do you think git is for and why do you use it? This would help me enormously to understand where you are coming from.

erwincoumans 5y ago
Git is a popular distributed versioning tool, but some commands have obscure syntax that is easy to get wrong, leading you into a mess that becomes a time drain. Creating a zip file of a git root folder takes seconds, and can get you out of the mess in seconds, rather than spending minutes or hours to undo some mess. If you can foresee git getting into a mess (and I can, after > 10 years of git experience), you can just take that backup to save time 'just in case' your git repo gets into that mess again. Changing the git commit history (for example because you made a commit under the wrong name/email address) in particular can cause huge headaches. Doing a git merge with tons of changes (think of clang-format white space changes in combination with various other commits) is another one. This is not about the specific cases where your git repo can become a mess, but more about having a simple safety mechanism to always get you out of the mess.
nkozyra 5y ago
> If you can't trust git to do this, how can you trust "cp" to make a copy of a file? I would love to get a genuine answer to my question: what do you think git is for and why do you use it? This would help me enormously to understand where you are coming from. All of us - at some point - were new to git and coming from other VCS systems meant there was a relatively steep learning curve. I also understand git fear - some of the stuff is a little arcane, and organizations are often very dogmatic and loud about their usage and approaches to git. It leads to a lot of gatekeeping. Do we rebase here? Do we never rebase? Linear history? Rebase feature branches or merge directly into main? It makes the fear of the tool that much stronger. `cp`, on the other hand, is pretty straightforward. There are no local approaches to using it, there's no real `cp` expert in-house at most places. It does what it says on the box without a lot of frills or options. git is a complex tool. It becomes easier the longer you use it, like most things, but it can be very intimidating to new or intermediate users.
- globular-toast 5y ago
  > All of us - at some point - were new to git and coming from other VCS systems meant there was a relatively steep learning curve. He's not new to it. He says he's been using it for over 10 years!
jcranmer 5y ago
> No, but I'm shocked git is so misunderstood that this would be considered a time to do this. You shouldn't be. As you say, you shouldn't need to do this, but the fact that so many people do feel the need to do this speaks to poor UI design on git's part. There are, I think, two main reasons why people feel the need to do this. The first is that git makes it really easy to rewrite history, without really offering much in the way of safety rails. You have but to be burned by this once to lose all trust in git whatsoever. And this is something where there are safer ways to rewrite history: Mercurial's concept of phases or changeset evolution is easily far better than git in this regard. Even exporting the excised revisions as a revset ("strip-backup") is far easier for me to undo than having to go into git reflog (especially because I don't need to race any `git gc` command--note that git is the only VCS that feels the need to have a garbage collector!). The second issue is that git has a lot of different places where state can be hiding, and it quickly becomes unclear which of the various places a command is affecting. Is this going to update my working directory, the most recent commit, the staging area, or multiple of those copies? If I'm in the middle of an interactive rebase, do I need to `git commit` or `git commit --amend` or some other command to properly update "the" commit? Maybe if you're fluent in git, it's all obvious, but if you're not fluent, it's way too easy to accidentally do the wrong thing. And looking up git documentation doesn't help--it's the only tool I regularly use where reading the documentation actively leaves me more confused than before I consulted it.
- globular-toast 5y ago
  > The first is that git makes it really easy to rewrite history, without really offering much in the way of safety rails It does, I just think they are not obvious enough because people haven't read an article like the one posted here. Git is an append-only data store. You can't lose anything as long as you have committed it. Rebasing does rewrite history, but it doesn't delete the old history. It's still there. The reflog links to it. The old remote tracking branch links to it. You could even leave a tag there to link to it. There are many ways to get back.
throwhauser 5y ago
Combining a small repertoire of git commands and this type of brute-force backup allows people to use git without having to learning all the details of its inner workings (or at least not having to keep that knowledge in everyday short-term memory.) If a small repertoire of git commands covers 95% of what a person needs git for, and recovering from backup covers the remaining 5%, why spend time and effort "git-ifying" that last 5%?
housecarpenter 5y ago
It's entirely possible to trust something to work one way (e.g. keep a trivially restorable backup of previous state) when you do one thing with it and not trust it to do the same thing when you do another thing with it (especially if it's something you do infrequently or have never done before). The advantage of cp compared to git is that it only does one thing (more or less), so you don't have the potential for "doing things you're unsure of" in the same way as git.
dec0dedab0de 5y ago
Backups and version history are not the same thing. Especially when you're messing with the version history. I make copies when I'm using git-filter-repo, or BFG. But even rebase is a destructive action that would be nice to have a safety net for. In the real world people have a ton of untracked files for their development environment, and uncommitted changes, but need an update from a coworkers branch that has a conflict with development, and a different conflict with your local changes. This can leave you in a weird state pretty quickly, and merge conflicts are a pain, especially if the conflicts are in a part of the code you're not very familiar with. Personally, I go full cowboy and work my way through it, but I am not surprised in the least when I hear that people make a backup so they can quickly restore. One benefit of copying a directory instead of using git is that it will copy all of your untracked files, and uncommitted changes as is. Another benefit is that it works the same no matter what tooling you're using. I believe that some legacy code at my company is still on SVN and source safe. I also use open source projects that are developed with mercurial, bazaar, and fossil. If I were going to work on any of them, I would definitely be making backups the standard way instead of trusting my ability to use the tool properly.