Hacker News new | past | comments | ask | show | jobs | submit login

> 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.


Fair enough, that all makes sense. I do push branches and hope people won't look at them if they aren't connected to PRs :)

> I don't trust any backup that requires me to remember and take a manual action.

(Google drive has an automatic sync client thing like Dropbox so all it involves is having a special local folder where I put documents I want backed up. Or indeed git repos. https://www.google.com/drive/download/)


> so all it involves is having a special local folder where

One last point. A backup shouldn't be "a special local folder" - it should be "all files on all drives unless I specifically exclude them"


I've never wanted that sort of backup in the last 20 years of computer usage. I think it's a bit old fashioned honestly. Nowadays a computer is an ephemeral thing; all that's persistent is files in the cloud, git repos, and provisioning config to get a new machine in a similar state to the last one. And yes I know "similar" there will have made your heart skip a beat :)


> I think it's a bit old fashioned honestly.

My backup is "the cloud". It's a remote store of my stuff.

I've got about 6tb of local storage attached to my two machines. I couldn't afford Google Drive or similar for that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: