Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dura is a background process that watches your Git repositories

github.com

Post reply on HN
Print view View original

201–207 of 207 posts

Re: Dura is a background process that watches your Git repositories

#201

Post by andybak »

da39a3ee wrote: post #197
andybak wrote: post #194

Earlier quoted context omitted.

> 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 peo…

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"

Re: Dura is a background process that watches your Git repositories

#202

Post by fivea »

int_19h wrote: post #178
fivea wrote: post #174

Earlier quoted context omitted.

> Along similar lines, I've adopted a hyper-frequent commit pattern in git. I do a bunch of meaningless micro-commits as I'm making progress, and then rewrite them all into one or two meanginful commits once I've reached a working state of whatever I was trying to do. Aren't you describing a feature branch? That frankly sounds like git 101.

Nope. A feature branch is still expected to have meaningful commits, and is usually used for collaboration between several coders. Its history doesn't get rewritten. What OP describes is a temporary work branch that belongs to a single person, and has a bunch of meaningless commits. So nobody else should be using it - or if they do, they need to sync with the owner, since the latter can squash or otherwise mutate com…

> A feature branch is still expected to have meaningful commits, and is usually used for collaboration between several coders.

No, not really. In fact, some issue tracking software equate feature branches with tickets, worked on by a single person.

> What OP describes is a temporary work branch that belongs to a single person, and has a bunch of meaningless commits.

Aka a feature branch.

Re: Dura is a background process that watches your Git repositories

#203

Post by da39a3ee »

andybak wrote: post #201
da39a3ee wrote: post #197

Earlier quoted context omitted.

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 :)

Re: Dura is a background process that watches your Git repositories

#204

Post by andybak »

da39a3ee wrote: post #203
andybak wrote: post #201

Earlier quoted context omitted.

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

Re: Dura is a background process that watches your Git repositories

#205

Post by int_19h »

fivea wrote: post #202
int_19h wrote: post #178

Earlier quoted context omitted.

Nope. A feature branch is still expected to have meaningful commits, and is usually used for collaboration between several coders. Its history doesn't get rewritten. What OP describes is a temporary work branch that belongs to a single person, and has a bunch of meaningless commits. So nobody else should be using it - or if they do, they need to sync with the owner, since the latter can squash or otherwise mutate com…

> A feature branch is still expected to have meaningful commits, and is usually used for collaboration between several coders. No, not really. In fact, some issue tracking software equate feature branches with tickets, worked on by a single person. > What OP describes is a temporary work branch that belongs to a single person, and has a bunch of meaningless commits. Aka a feature branch.

I guess we'll have to agree to disagree, then. In my 20 years in this industry, I've never seen a feature branch like that.

Re: Dura is a background process that watches your Git repositories

#206

Post by jsnelgro »

elpakal wrote: post #103
bastardoperator wrote: post #66

Earlier quoted context omitted.

What you're describing is how git should be used. I would add it's important to push your branch to the remote just in case something happens to the local copy. I tend to squash/rebase to get the same type of results, but I can't imagine not saving work regularly or being concerned with the commit history while I'm actively working.

I usually commit often locally and push to remote right away. Then when I want to open up my PR, I use `git reset --soft ` where target is the local version of the target branch in my PR. That resets all the commits, but keeps all the changes in the staging area, and then I can clean up my history. Then I force push to override what's there. This works well for my workflow because we squash all commits into target br…

I just gave this workflow a shot and it was great. Thanks for the tip! Do you use anything for committing more granular chunks of code? I'm just committing groups of files but after reading about magit on other hn threads, I feel like I could do better.

edit: added question

Re: Dura is a background process that watches your Git repositories

#207

Post by whoomp12342 »

Quekid5 wrote: post #196
dijonman2 wrote: post #185

Earlier quoted context omitted.

A commit every 60s sounds terribly inconvenient unless it’s automatic. I share OP’s workflow patterns and it works for me. I also don’t use an IDE.

I don't mean 60s literally. I mean arbitrarily small commits at your own convenience. You don't need to have even remotely working code when you commit, is the point. You just commit whenever. (It's almost like saving files, just commit.) I think the word 'commit' might have been a mistake, now that I think about it. Maybe 'snapshot' would have been better.

yeah, I mean its situational and sometimes I will do that, but 90% of the time staging does what I need for temp backups
Post reply on HN