Hacker News Reader

Comment by mattnewton | Hacker News Reader

Why not just keep working? That next commit will work just fine without a central server.

At some point there has to be centralization. We are deploying one product, not N products for N commits. If I can't push, I can't have CI build my branch, and I can't submit a PR for review.

But you could continue working and only have to apply minor patches forward if you later find your starting point needed to be fixed.

You don't have to wait for CI, just create a new branch and continue your work as though CI passed, and your PR was accepted. If that comes true you don't need to worry much, just rebase and continue.

On the other hand if you find out you needed to make changes - do those on the branch you made those changes, and finish your PR/CI cycle. Then go to the new branch you continued work on and rebase, and continue.

Is there something I am missing?

Heaven forbid we find a reason to take a break

In the old days at least we had compiling. Not so much anymore.

No, today we have something else to wait for, it is called the runtime.

But users wait for that, I can get on with finding a new framework instead.

npm install

And when you need to delete your node_modules folder for the upteenth time, it's a nice 5 minute break.

He said a break, not a vacation

But you can technically spin up another git server, you can spin up as many git servers as you need and the same code will be there. I do understand what you mean though, been there. Organizations may not be happy with hearing that they need multiple places to store code.

you can totally push to each other dev machine as needed, so that covers reviews. and just get the guy responsible for maintaining ci to fetch from everyone machine and push to the build server, or you can configure that to pull from this guy pc if needed depending on your ci

It should be easy to move the center. Having a single 3rd party be the only central point you have available is asking for trouble.

Because we forget how to let go of all this work stuff and get sucked into it. There is a life out there too. some one us can balance, some find it hard. this is an opportunity to just pause for a few minutes. Mentally pause.

Right. There's an entire world out there of of personal projects and open source contributions you can be doing when not working.

People get so caught up in their daily coding they forget about all the other fun coding they could be doing outside of work.

It's a shame.

Or, not coding.

I think there was a joke in there ;-)

Of course, you know that, I know that, we all know it - but our bosses don't ;)

They are living in the technical stone age then. Time on keyboard does not equate good productivity. Happiness, balance, freedom - that increases output.

Because programmers always need a break. Don't go giving our bosses ammo. It's compiling, it's uploading, Github is down. Have some compassion.

merging work with contractor right now...

That works too, believe it or not. Just add another remote and pull it.

I only coordinate my remotes through github. I don't use git in "decentralized mode".

That's not something you decide once at the beginning and get stuck with it. You can reevaluate that decision at any point and easily add more remotes to a git repo on the fly.

So, uh, it's not clear what exactly people are expecting me to do here. Wire up my repo to my contractors temporarily (not even sure how I'd do that as i don't have access to their machines or filesystems) then detach when github is back (it's already back)?

A single repo can have many remotes. Adding additional remotes does not prevent you from also using old remotes, nor do you ever have to remove a remote that you intend on using again in the future.

Obviously it's a moot point for you now, but getting comfortable with how git remotes works is something that could pay dividends for you in the future.

I have multiple remotes already and know how they work. What I'm asking is, if github is down, and I don't have ssh or other access to my contractor's repo on their machine, what is my remote supposed to attach to?

Also, the additional effort to manage multiple remotes is entirely nontrivial.

I believe git was originally designed to share commits via email.

Here is one of the top hits searching "git email patch"

https://thoughtbot.com/blog/send-a-patch-to-someone-using-gi...

They can always tar up their repo and send it over. You then unpack it on your end, then set it as a remote, pushing/pulling from it as you see fit. Admittedly, not the greatest workflow, but it doesn't require any new tools if you are already familiar with remotes.

As another alternative, git-format-patch/git-apply or git-bundle may be a quicker way of shipping changes around.

1. Send a series of patches in an email.

2. Send a branch in whatever file exchange service you use. (Also formatted as patch series)

3. Setup ad-hoc vpn (zerotier?) and setup remote via SSH.

4. Push the branch into a private repository on a different service (private gitlab?)

5. Spin up a free t2.micro on AWS and push the branch there.

There are lots of options.

You don't need write access to a remote for that remote to be useful. Two or more people can collaborate using public repos that others may fetch from but not push to. Then, in lieu of github PRs, you request other people pull from you with email or however you like.

If you need access control without VPNs or whatnot (or if you simply want something closer to the github workflow), there are other services similar to github that can almost certainly provide what you need, such as gitlab.

> "Also, the additional effort to manage multiple remotes is entirely nontrivial."

With practice, I'd say it asymptotically approaches trivial.

A lot of people do that too.

Reply on news.ycombinator.com