4 ms·

Dropbox's desktop client is STILL the only desktop client that doesn't suck or choke on multiple git repos. Aside from syncthing it is the only program that I c

Dropbox's desktop client is STILL the only desktop client that doesn't suck or choke on multiple git repos. Aside from syncthing it is the only program that I can count on to get file synchronization right

scarface_74 3y ago
Why would I use Dropbox for my git repos instead of just using - a purpose built hosted git server?
- pdntspa 3y ago
  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

Why would I use Dropbox for my git repos instead of just using - a purpose built hosted git server?

pdntspa 3y ago
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.