Comment by da39a3ee
4 years ago
> There are too many gaps between "what I want to commit to a repo" and "what I would hate to lose in the event of a total system failure".
You’re thinking about commit wrongly. You should commit all the time, and make use of branches liberally, and push branches to a remote for backup. Then, you should form your “permanent” commits from that work. The thing is, you have to get comfortable with git. For example, one common move is:
1. Commit everything 2. Make a temp branch (remember that “branches” are just labels for a commit; they cost nothing) 3. Switch back to the first branch 4. Use git reset to uncommit the last few commits 5. Clean up the code and commit it properly, with a good commit message 6. Run tests and check the diff from your temp branch to check you didn’t make a mistake when cleaning up
This tool Dura is totally unnecessary for people who are comfortable with git.
> You’re thinking about commit wrongly. You should commit all the time, and make use of branches liberally,
I agree - but that doesn't invalidate my original statement. I think you might have misunderstood my point. See my other reply above.
Yes, I think I stick to my ground. I'll address your points below. There are two camps here:
1. A large number, possibly a majority, of people who aren't yet familiar enough with git. Those people think of commits as being final: a commit is what you will push to the remote, your colleagues will see, and gets stored in public git history forever. They haven't yet learned that branches cost nothing, how to work with temporary branches, and how to create a new series of commits from already-committed work.
2. People who know git well and are the complement of the above set in all ways.
I'm sure you're right that backup systems have their place, but your comments here about how git shouldn't be used for backups are aligning with the camp (1) folks and making it harder for them to see that git can be used to save their work frequently, once they learn git better. Ultimately, positions like the one you're taking contribute to people developing misconceived tools such as TFA.
> 1. everything else on your system (potentially - a lot of stuff depending on your workflow
Sure -- backing up random files is good. I use google drive for that personally.
> 2. everything you've .gitignored (you 100% sure that's all ok?)
Yes, I don't worry about this. .gitignore is itself under git's control, so whatever's gitignored for me, is gitignored for my colleagues, therefore the project works without standardized content in those file paths.
> 3. changes not yet pushed
What reason is there ever to not push a branch that contains work you wouldn't want to lose? Planes and other no-network situations is one: I just push as soon as I'm on network. I never leave valuable work unpushed if I have a network connection.
> 4. branches that don't exist on remote
Why haven't you pushed them?
> 5. git stuff that's invaluable for disaster recovery
Not sure what you mean here
> 6. git stashes
Yes, good point to raise. Store work you're not prepared to lose in branches, and push them. You can stash it as well if that's convenient.
You probably know this, but the biggest hurdle newcomers to git face is they don't understand that branches are cheap, and they don't understand how easy it is to undo changes by using temp branches with `git reset --hard` and `git checkout`. Rather than telling them to supplement git with a backup system, it would be better to teach them to get comfortable using git. TFA is an extreme example, talking as if ctrl-z undo is an inevitable workflow for a git user when, in fact, it's only something that beginners do for more than trivial undo operations.
> I use google drive for that personally.
I don't trust any backup that requires me to remember and take a manual action.
> > 3 . changes not yet pushed > > 4. branches that don't exist on remote > Why haven't you pushed them?
Fair point. Because I'm mainly working in public repos, it's psychological. It requires some degree of mental effort whenever I think about pushing something because it's then in public for people to see. I judge people on their public commits so I rather suspect people will do the same as me. "Naming things is one of the hard problems in computer science" - a public commit requires several naming decisions (commit message, branch, deciding "foo" is not a great name for a variable). I sometimes don't want to break my flow to make those decisions. And sometimes that means I put off a commit for longer than I should.
Whereas - my backup happens automatically and continually. It's not tied to my indecision, choices or personal failings. It just works.
So - I strongly recommend everyone uses version control. And I strongly recommend they augment it with AUTOMATIC off-site backups.
4 replies →