Hacker News Reader

Comment by Waterluvian | Hacker News Reader

Correct me if I’m wrong but these all seem to fix problems that exist in a local clone only. And that’s where none of my “oh shit” moments happen.

All of my oh shit moments are two flavours: I have pushed to remote, or I have pushed to remote and force pushes are disallowed.

I want a list of as graceful solutions as possible for those scenarios. And certainly they can be real-world solutions like “this cannot be undone in a desirable way so here’s an approach to handle the commit(s) necessary to fix the problem.

This also brings up a question I didn’t realize I had: are people using git without frequently pushing to remote? I feel like having a remote backup of my work in progress is the killer feature. I can’t imagine doing any amount of work and not backing it up.

View on HN

> are people using git without frequently pushing to remote? I feel like having a remote backup of my work in progress is the killer feature.

I use git without a remote pretty often. When doing personal projects or exploratory work, the problem is either so trivial that I don't care about backup, or already backed up using something like Nextcloud/Syncthing. But having the commit history allows me to easily look at old code, revert changes, and make big structural changes without having to back up the entire project folder in case I end up disliking the new structure.

I guess you're just not working on many things at a scale where version control is useful but setting up an online repo doesn't seem worth the time.

When I do exploratory research, having a history of commits, days, months, years after the end of the research project is invaluable for many possible future needs.

I’m still not sure I see a strong case for not bothering with a remote. But I appreciate we all do things at different fidelities.

> I guess you're just not working on many things at a scale where version control is useful but setting up an online repo doesn't seem worth the time.

It is literally a couple of clicks to set up a private repo on github. For me, either the problem is too small to set up git, or it is big enough to spend half a minute to create a github repo.

Pro tip: you can set up a remote repo on any Unix machine with SSH access:

   ssh machine "mkdir x; git init x"
   git clone machine:x

If you have something sensetive or just want to avoid github/gitlab for some other reason, an empty remote container with SSH access works just as well.

You could just set up a private Github monorepo for all your utility projects and experiments. One branch per project, and you check out exactly the branch you want. Since 2012, `git clone` supports `--single-branch`, which makes it download only the commit history of that specific branch.

A git remote is not a backup. I could make a mistake, force push the wrong thing to the wrong place and lose a bunch of stuff.

That’s why we disable force push. Then it’s a nice historical backup.

That's not really true. It is pretty difficult to delete any data from git, especially by accident. You may screw up your history but you can always fix that if you know what you are doing.

If I force push to the wrong branch on github, is it possible to access the remote reflog to try and recover from my mistake?

Yes. Git push does not remove the previous commit, but changes the HEAD of the branch to be another commit.

The old commit becomes unconnected, but you can still get to it if you know its hash. There's also a way to list all unconnected commits, which is a bit involved.

Unconnected commits will exist and take up space until garbage collection is done.

If you pushed by mistake on a remote branch instead of creating a PR from a new branch, then you revert the commit, you're going to have trouble with the PR not showing all the changes because they match the orphaned commit.

Note that PR is not a fundamental git concept, but something a code forge can decide to implement any way they like. I presume you're talking about GitHub, because in GitLab, you will be able to see all changes when browsing commits constituting the merge request.

You could recover using your local reflog I think.

> force push

The solution is simple: never use push --force. Without that, everything in git is recoverable.

Is this a general rule? If so, I'd appreciate a suggested best practice for the following case: say I commit, push, then a while later fix some minor error and don't want it to be a separate commit (otherwise my commit history would get unmanageable). So I gc --amend and then gp --force. What would be the correct way to do this?

For the specific thing you want, force push is the only way AFAIK. However, my argument is that you should let the commits reflect the true history of the code. Fix the minor error and explain it in the message.

The downside of the "true history" approach, besides obvious aesthetic reasons, is that it precludes the use of such tools as `git bisect` and `git blame`.

Sure. But it’s better to disable it upstream. Otherwise you get hotshots and people with bad habits joining your company and doing naughty things.

Not having a remote is the killer feature of DVCS.

That and multiple remotes. Not even necessarily all having the same branches.

I used to use local-only git often. But now that private repos on github are free and take two seconds to create, I keep online backups of everything.

There's a reason commit and push are two separate actions. That said, most people commit+push in the same keystroke.

git revert is my best friend.

What is the reason? Like are people just not pushing changes to remote branches? Or is there some value in stuff to do in the small time between commit and push? Like are you checking your work before pushing?

In the past I've done stuff like not pushing until the end of the day/coding session. Usually though I just end up committing and pushing immediately and then realizing I need to amend something and make a note to rebase later(I totally always do that rebase /s).

I try to keep my commits small, and I don't push each time because I have a Jenkins pipeline thats going to update a server for my branch and run unit tests and all that

Intermediate commits. For example, while building a UI - HTML is done, but you haven't begun styling. You want to be able to revert to a good point in case you screw up, but there isn't much reason to push it to a remote because it's not a shippable state. As long as your computer is being backed up (you are using backups, right?) you won't lose any data by not pushing to a remote.

Reply on news.ycombinator.com