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.
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
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.
> 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?
> 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.
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.
If I change 10 files as one logical change. I want to ensure that when I go to the other computer I have all 10 of those changes. DropBox by definition is eventually consistent. You don’t know if all of your changes are synced.
That’s not even to mention when I use an automatic refactoring tool that can literally change dozens of files.
My whole original point to this thread was that the dropbox client can handle tens of thousands of little file changes without breaking a sweat. You could replace text in the entire codebase with one command and it will swallow it all no problem. Yes it is eventually consistent, and yes dont touch the code on any other devices until it's done, but even if you are somehow refactoring your entire codebase every day, the change will be made manifest, and quickly.
I don't know if you've ever peeked under the hood of a git repo, but it creates literally thousands upon thousands of tiny little files. Far more than whatever the repo is actually storing.
For my uses, where I would run over to a machine and maybe tweak a line or two of code on the laptop and re-run it then return to my desk, there were literally never any problems if I didn't jump the gun (and it was easy to resolve if I did).
And this compares to knowing that when I do a git add/git commit/git push, I know my code is on the server.
When I do a git pull, I know my code is on the second computer.
> Yes it is eventually consistent, and yes dont touch the code on any other devices until it's done
Again, this is literally a problem that git was purpose built to solve and used by millions of developers every day across the industry from the smallest shop up to largest companies.
In any case, I wasn't the engineer responsible for merging things to the development branch. And that person worked by doing the merge in github, without squashing anything. If you git hygiene sucked your PR gets rejected.
That’s the entire idea behind squashing commits before you merge them or request a pull request.
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?
And that’s just it. When you go to your other computer you don’t know that Dropbox has synced all of your changes.
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.
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?