4 ms·

Or just have a monorepo :)

kingosticks 8y ago
Operations on monorepos can be so slow that having multiple copies checked out (e.g. different branches) is a thing (ideally using worktrees).
- giancarlostoro 8y ago
  I hate to say it but because I don't feel comfortable with git enough whenever I am about to do anything outside of my comfort zone I make a hard copy of my whole directory just to be sure if I get myself into a FUBAR state I can delete the FUBAR'd directory and copy it again. This has saved me many a headache. Also gives me a fresh state from which to ask for help from. Anytime the word rebase is mentioned my coworkers shriek.
  - the_duke 8y ago
    You should really work through some Git tutorials. I haven't done that since using SVN 10 years ago. `git {branch,diff,stash}` should be all you need for this. Especially working with the stash will be a big productivity boost for you.
    - giancarlostoro 8y ago
      Most of what I do is handled by my tooling for me. It's when I have to do more than just the basics that UI tools somewhat fall short. I prefer the UI that JetBrains IDE's give because I can see visually what I am about to commit. I've made a lot less mistakes than my colleagues who either don't pay attention to the UI or swear by the command line but still miss simple things quite often, the worse I do is a typo here or there which a command line approach would of never saved me from either. To be fair I don't even remember anymore when I've had to do anything extensive, it's been quite a while. I'm even able to handle merge conflicts right away from within my editor.
  - kingosticks 8y ago
    Have you ever had a look at the combination of 'git reflog' and 'git reset --hard <ident>'? You can find the point before you did the uncomfortable operation and restore your state to exactly then. Saves having to make that backup copy (which, again, can be slow for a big repo).
    - pjc50 8y ago
      Neither of those saves the working directory, though. So uncommitted work "feels" at risk while typing unfamiliar git commands. (I now consider myself pretty good with git as a result of being forced to learn gerrit, but I also still remember the early painful days)
      - kingosticks 8y ago
        True, that's a good point.
- pjc50 8y ago
  This is one remaining huge advantage of centralised VCS systems which has been overlooked in the fad for git.
  - kingosticks 8y ago
    I don't follow, what's the specific advantage here? And just for context, we use both git and a cvs (yes, it's still going!) at day job. Both are pretty slow.
    - pjc50 8y ago
      Since a centralised system doesn't carry all the history with every checkout, the checkouts are smaller and there's less risk of running out of SSD space with a large monorepo. It's also quicker to make a new one. svn/p4 will let you checkout a subtree of a "monorepo". p4 in particular is pretty fast, although as a closed source CASE tool its days must be numbered. (re: carrying all the history, I used to work somewhere where they checked the build artefacts in to svn on every release build. A naive "git svn" import was in the 10s of gigabytes.)
      - kingosticks 8y ago
        We don't have space issues on our machines but you are right, you don't need multiple copies of the entire history and that's why I suggested the worktree feature.
        pjc50 8y ago
        Thanks for suggesting that, I'd not realised it was possible.
  - nindalf 8y ago
    Did you just call git a fad? The vast majority of software in version control is in git, including some of the largest and most important open source projects. What else do you think is a fad? Linux? C?

Operations on monorepos can be so slow that having multiple copies checked out (e.g. different branches) is a thing (ideally using worktrees).

giancarlostoro 8y ago
I hate to say it but because I don't feel comfortable with git enough whenever I am about to do anything outside of my comfort zone I make a hard copy of my whole directory just to be sure if I get myself into a FUBAR state I can delete the FUBAR'd directory and copy it again. This has saved me many a headache. Also gives me a fresh state from which to ask for help from. Anytime the word rebase is mentioned my coworkers shriek.
- the_duke 8y ago
  You should really work through some Git tutorials. I haven't done that since using SVN 10 years ago. `git {branch,diff,stash}` should be all you need for this. Especially working with the stash will be a big productivity boost for you.
  - giancarlostoro 8y ago
    Most of what I do is handled by my tooling for me. It's when I have to do more than just the basics that UI tools somewhat fall short. I prefer the UI that JetBrains IDE's give because I can see visually what I am about to commit. I've made a lot less mistakes than my colleagues who either don't pay attention to the UI or swear by the command line but still miss simple things quite often, the worse I do is a typo here or there which a command line approach would of never saved me from either. To be fair I don't even remember anymore when I've had to do anything extensive, it's been quite a while. I'm even able to handle merge conflicts right away from within my editor.
- kingosticks 8y ago
  Have you ever had a look at the combination of 'git reflog' and 'git reset --hard <ident>'? You can find the point before you did the uncomfortable operation and restore your state to exactly then. Saves having to make that backup copy (which, again, can be slow for a big repo).
  - pjc50 8y ago
    Neither of those saves the working directory, though. So uncommitted work "feels" at risk while typing unfamiliar git commands. (I now consider myself pretty good with git as a result of being forced to learn gerrit, but I also still remember the early painful days)
    - kingosticks 8y ago
      True, that's a good point.
pjc50 8y ago
This is one remaining huge advantage of centralised VCS systems which has been overlooked in the fad for git.
- kingosticks 8y ago
  I don't follow, what's the specific advantage here? And just for context, we use both git and a cvs (yes, it's still going!) at day job. Both are pretty slow.
  - pjc50 8y ago
    Since a centralised system doesn't carry all the history with every checkout, the checkouts are smaller and there's less risk of running out of SSD space with a large monorepo. It's also quicker to make a new one. svn/p4 will let you checkout a subtree of a "monorepo". p4 in particular is pretty fast, although as a closed source CASE tool its days must be numbered. (re: carrying all the history, I used to work somewhere where they checked the build artefacts in to svn on every release build. A naive "git svn" import was in the 10s of gigabytes.)
    - kingosticks 8y ago
      We don't have space issues on our machines but you are right, you don't need multiple copies of the entire history and that's why I suggested the worktree feature.
      - pjc50 8y ago
        Thanks for suggesting that, I'd not realised it was possible.
- nindalf 8y ago
  Did you just call git a fad? The vast majority of software in version control is in git, including some of the largest and most important open source projects. What else do you think is a fad? Linux? C?