4 ms·

You're not hosting the repos on there, you're syncing changes between computers you frequently have to switch back and forth on, without all the git command cer

You're not hosting the repos on there, you're syncing changes between computers you frequently have to switch back and forth on, without all the git command ceremony When I was doing embedded linux development I'd frequently have to get up from my seat to go test something on actual hardware. Necessitating a laptop and a desktop.

scarface_74 3y ago
What git ceremonies? git add . git commit -am “…” On the other computer git pull. I know that I have all of my changes synced to and from the server as one “transaction”. With Dropbox you are dealing with eventual consistency. And besides you get all of the affordances of purpose built tools and hosting your git repository at a place that understands git.
- pdntspa 3y ago
  A couple of things: git add ., git add -u, etc, etc... bulk adds like that are bad git hygiene Nonconstructive commit messages like "..." are similarly awful. And don't forget to git stash/git stash pop Put yourself in the shoes of another developer who has to parse all that crap in the commit log. At my last job that sort of thing would never pass code review. To say nothing of the fact that you're typing all these commands potentially several times an hour, sometimes every day, for years, and adding an additional distraction to something that I got down to a pretty tight feedback loop. One alternative, the one I like the most, is you link your folders with some kind of sync mechanism (Dropbox) and can then freely (within limits) switch back and forth, and you can do all your surgical commits at once, at your leisure, once the code is ready to be backed up. If the system is reliable it is quite pleasant to experience. As a bonus you're not encoding every harebrained idea into your organization's permanent memory
  - rahkiin 3y ago
    Why not use branches, and squashing in the end? Then it is not permanent, your commit messages do not matter, but you also do not need external synchronization with a third party.
    - DelightOne 3y ago
      5 commands that when you forget them or when they go wrong you have to manually fix. And where when you automate them you realize on your laptop that something went wrong and you have to go back and fix it, possibly losing hours depending on where your other computers are. Who would want that, possibly over many repos? Git isn't even working well with large files to be synced. Think about git submodules. So much can and does go wrong because Git is not designed to sync that way. Not worth the hassle for most people.
      - scarface_74 3y ago
        You sound like the old guys (I’m 50) who are saying who needs all this git stuff instead of just putting the code on a network share. > So much can and does go wrong because Git is not designed to sync that way. Not worth the hassle for most people. Git isn’t worth the hassle for most developers??? And you really don’t see the issue with non atomic syncing for code repositories using DropBox?
        pdntspa 3y ago
        I get that you really really love git, but I am not you, nor is anyone else. We all have our own preferences. I don't like typing in tons of commands do so something simple when other tools exist. I like neat commits with a tidy explanation as to why they are there (preferably including the ticket/issue number), and I like them to persist through the life of the software. > And you really don’t see the issue with non atomic syncing for code repositories using DropBox? The only problem that ever came up in five years of this was that I could occasionally get a conflict if I switched too quickly. But that was easy to resolve, and Dropbox would always sync within 5 to 10 seconds. And no we did not have a network share to work from. The wifi in the building was horrendous so it was preferable to have everything local.
        scarface_74 3y ago
        > We all have our own preferences. Your preference literally goes against every agreed upon best practice by every organization I’ve worked for for over two decades. > The only problem that ever came up in five years of this was that I could occasionally get a conflict if I switched too quickly This is literally the problem that git tools solve with merging changing.
  - FridgeSeal 3y ago
    I’m reasonably confident the comment was using those commands as general workflow examples, and not exact, concrete commands to issue. Nobody is suggesting you have to push this to stuff to main, use a branch if you don’t want to get in everyone else’s way or require code reviews?
    - pdntspa 3y ago
      No, I don't think so, git add . / git add -u are what you use when you quickly want to vacuum up all your changes and commit them in one fell swoop
  - scarface_74 3y ago
    You should be working on a branch anyway and doing a git squash and then merge it. And that’s just it. When you go to your other computer you don’t know that Dropbox has synced all of your changes.
    - pdntspa 3y ago
      At my last job we did exactly that (no squash though), then our branch got merged to the development branch and the commit messages would be all stacked on top of each other. But we had a policy to include the jira ticket in all commit messages so the commit messages were still useful. Imagine if it was just lines of ... and "checkpoint" and what not. If YOU want to go back and clean up after the fact, that's fine. I don't want to do that. > And that’s just it. When you go to your other computer you don’t know that Dropbox has synced all of your changes. That's what I meant about reliability. You CAN trust that dropbox syncs it after a few seconds. You don't need guarantees of atomicity, you just need to be sure that you're only using one machine at a time. Which was an easy rule for me. That is the whole point. Also, you are very consistently making a lot of assumptions about me and how I work that are incorrect. I suggest you think on this.
      - scarface_74 3y ago
        > At my last job we did exactly that (no squash though), then our branch got merged to the development branch and the commit messages would be all stacked on top of each other. But we had a policy to include the jira ticket in all commit messages so the commit messages were still useful. This is against every best practice since I started using git over a decade ago. > You don't need guarantees of atomicity Am I really having this argument in 2023 that you should be using a code syncing process that guarantees atomicity?

scarface_74 3y ago

What git ceremonies? git add . git commit -am “…” On the other computer git pull. I know that I have all of my changes synced to and from the server as one “transaction”. With Dropbox you are dealing with eventual consistency. And besides you get all of the affordances of purpose built tools and hosting your git repository at a place that understands git.

pdntspa 3y ago
A couple of things: git add ., git add -u, etc, etc... bulk adds like that are bad git hygiene Nonconstructive commit messages like "..." are similarly awful. And don't forget to git stash/git stash pop Put yourself in the shoes of another developer who has to parse all that crap in the commit log. At my last job that sort of thing would never pass code review. To say nothing of the fact that you're typing all these commands potentially several times an hour, sometimes every day, for years, and adding an additional distraction to something that I got down to a pretty tight feedback loop. One alternative, the one I like the most, is you link your folders with some kind of sync mechanism (Dropbox) and can then freely (within limits) switch back and forth, and you can do all your surgical commits at once, at your leisure, once the code is ready to be backed up. If the system is reliable it is quite pleasant to experience. As a bonus you're not encoding every harebrained idea into your organization's permanent memory
- rahkiin 3y ago
  Why not use branches, and squashing in the end? Then it is not permanent, your commit messages do not matter, but you also do not need external synchronization with a third party.
  - DelightOne 3y ago
    5 commands that when you forget them or when they go wrong you have to manually fix. And where when you automate them you realize on your laptop that something went wrong and you have to go back and fix it, possibly losing hours depending on where your other computers are. Who would want that, possibly over many repos? Git isn't even working well with large files to be synced. Think about git submodules. So much can and does go wrong because Git is not designed to sync that way. Not worth the hassle for most people.
    - scarface_74 3y ago
      You sound like the old guys (I’m 50) who are saying who needs all this git stuff instead of just putting the code on a network share. > So much can and does go wrong because Git is not designed to sync that way. Not worth the hassle for most people. Git isn’t worth the hassle for most developers??? And you really don’t see the issue with non atomic syncing for code repositories using DropBox?
      - pdntspa 3y ago
        I get that you really really love git, but I am not you, nor is anyone else. We all have our own preferences. I don't like typing in tons of commands do so something simple when other tools exist. I like neat commits with a tidy explanation as to why they are there (preferably including the ticket/issue number), and I like them to persist through the life of the software. > And you really don’t see the issue with non atomic syncing for code repositories using DropBox? The only problem that ever came up in five years of this was that I could occasionally get a conflict if I switched too quickly. But that was easy to resolve, and Dropbox would always sync within 5 to 10 seconds. And no we did not have a network share to work from. The wifi in the building was horrendous so it was preferable to have everything local.
        scarface_74 3y ago
        > We all have our own preferences. Your preference literally goes against every agreed upon best practice by every organization I’ve worked for for over two decades. > The only problem that ever came up in five years of this was that I could occasionally get a conflict if I switched too quickly This is literally the problem that git tools solve with merging changing.
- FridgeSeal 3y ago
  I’m reasonably confident the comment was using those commands as general workflow examples, and not exact, concrete commands to issue. Nobody is suggesting you have to push this to stuff to main, use a branch if you don’t want to get in everyone else’s way or require code reviews?
  - pdntspa 3y ago
    No, I don't think so, git add . / git add -u are what you use when you quickly want to vacuum up all your changes and commit them in one fell swoop
- scarface_74 3y ago
  You should be working on a branch anyway and doing a git squash and then merge it. And that’s just it. When you go to your other computer you don’t know that Dropbox has synced all of your changes.
  - pdntspa 3y ago
    At my last job we did exactly that (no squash though), then our branch got merged to the development branch and the commit messages would be all stacked on top of each other. But we had a policy to include the jira ticket in all commit messages so the commit messages were still useful. Imagine if it was just lines of ... and "checkpoint" and what not. If YOU want to go back and clean up after the fact, that's fine. I don't want to do that. > And that’s just it. When you go to your other computer you don’t know that Dropbox has synced all of your changes. That's what I meant about reliability. You CAN trust that dropbox syncs it after a few seconds. You don't need guarantees of atomicity, you just need to be sure that you're only using one machine at a time. Which was an easy rule for me. That is the whole point. Also, you are very consistently making a lot of assumptions about me and how I work that are incorrect. I suggest you think on this.
    - scarface_74 3y ago
      > At my last job we did exactly that (no squash though), then our branch got merged to the development branch and the commit messages would be all stacked on top of each other. But we had a policy to include the jira ticket in all commit messages so the commit messages were still useful. This is against every best practice since I started using git over a decade ago. > You don't need guarantees of atomicity Am I really having this argument in 2023 that you should be using a code syncing process that guarantees atomicity?