Hacker News Reader

Comment by erwincoumans | Hacker News Reader

"In this case, the conflicting result is left in the working directory for the user to fix and commit, or to abort the merge with git merge –abort."

I've used git for many years, and I still zip the repo folder, before doing a large merge, since 'fix the commit' can be a large effort with conflicts. Quickly renaming the repo root folder, then unzipping the old version can be quicker/safer, if you are not a git ninja and don't want to loose any work. There is probably proper command for it, but I sometimes get into a git mess that I cannot get out of. (reading stack overflow, trying get reset, git checkout, git reset --hard and so on)

View on HN

Quick tip: Git branches are cheap. Like super-cheap. IF you want to create a safe point just before doing a tricky merge, just spin off a new branch pointing at the current commit:

git branch blah_branch_backup

Later, if your merge gets completely messed up, you can do:

git merge --abort

git reset --hard blah_branch_backup

That final command will restore the current branch's HEAD to point to the same commit as blah_branch_backup.

This same pattern is useful for other dangerous commands, like rebases or filter-branch.

When you're done, just delete blah_branch_backup.

You can also use git-reflog to restore the branch back to the state it was before the merge. So instead of creating a temporary branch, you can inspect the reflog, find the entry before the merge commit and do git reset --hard HEAD@{X}.

That's true! I personally prefer having a symbolic name for my backup, but the reflog is also very useful for "oops" moments.

Afaik git branches are merely pointers to commits, so it makes sense, that one can go back finding the correct commit id.

reflog saved me a few times, just remember that commits not referenced by a pointer (like HEAD or branch) can be GCed and disappear at any point. They are likely to be there right after a merge/rebase is finished, but may not be there anymore an hour later.

I create backup branches all the time. Though I rarely have to use them, they have saved my butt a couple times!

You don't need to create backup branches ahead of time with git, because the reflog saves every branch before every operation. You can create your backup branch from the reflog _after_ you discover you need it!

I did use the reflog once, when I forgot to make a backup branch. It's not one of the commands I use regularly though.

Thanks, I should have been mote precise in my post. I meant, I zip repo root folder before a complex git operation (certainly not before every single merge).

One example: changing the commit email, somewhere on the middle of many commits. On github, I sometimes need to use the work email instead of personal email (due to https://github.com/apps/google-cla) Changing the email of an existing commit messed up my repo beyond repair. This is just one example from memory, it happens infrequently luckily. Thanks for the git tips :)

That's exactly the sort of operation for which backup branches can help.

When you rewrite history, Git makes new commit objects that have the same topology as the original branch topology. It also updates the branch pointer to point at that new HEAD commit.

History rewriting commands essentially just fork the repo at some point in the past and create an alternate commit history. The original commits still exist, at least for a little while. Git will eventually garbage-collect them.

By creating a backup branch, you're "pinning" those old commits. With the backup branch in place, after you run a command that rewrites history, you will be able to look at the commit graph and see the point where the backup branch and the rewritten branch diverged.

I used to do what you do until I learned more about how Git works internally. And Git's really not super complicated at its core. I think much of Git's complexity comes from the minutiae of the CLI options. (For example, when you want to delete something, do you use `-d` or an explicit `remove`? It depends on the command you're running.)

But hey, if you have a workflow that works, then you do you.

> git branch blah_branch_backup

Don’t forget to commit your changes if you’re going to `reset --hard` later!

> There is probably a proper command for it

Before you merge, the command is “git merge --abort”. After you merge, the command is “git reflog” to show your history, and then something like “git reset --hard HEAD@{1}” where the number in braces is the reflog entry you want to restore.

Reflog is the ultimate undo tool for work that’s been committed, it’s like having an infinite Ctrl-Z. If you use reflog to restore before your merge, you can even use it again to restore your mess, or to restore a different merge before the one you made a mess of.

The one thing you can’t recover using reflog is an accidentally dropped git stash. This is one reason I try to avoid stashes, and just use lots of one-off branches instead.

I'm the same - although I've had many experiences in the past where I avoided the time-saving tools because they were too complex in the moment and then kicked myself later on when I realized just how much time I had been wasting by avoiding spending ten minutes learning the time saving tools, every time I try to do a git merge "the right way", I end up with conflicts that shouldn't be conflicts and changes that I didn't want to pull in that I have to manually undo until I just give up and "manually" merge.

"Zipping the folder" and keeping a copy of it is literally the sole purpose of a version control system. These kind of comments baffle me, quite honestly. But that is my fault, not yours.

Could you tell me what you think git is for and why you use it?

Congrats never getting into a time consuming git mess, but I do sometimes. This is a very rare event. Recently I tried changing the committers email (each commit has a name and email attached) but that commit was already pushed into the repo, and I could not recover from the resulting mess. Even had to delete my github fork, and fork again. Happens about twice a year, while I used git commits many times every day.

You misunderstand. Do you think I was born understanding how git works? I've messed up at least as much as you, but I spent the time learning how it works rather than going nuclear and deleting the repository. I can't relate to how you think about git because it's been too long for me, that's why I asked if you could explain it from your point of view.

Ooof. What a useful contribution to the discussion.

This sort of use case makes sense to make a copy of the .git folder. When you are trying to rewrite the history of a whole Git repo, throwing away the repo and starting for a backup is often easier than trying to unwind changes.

Though in this specific case of rewriting emails, there is a way in git to do it without rewriting history:

https://git-scm.com/docs/gitmailmap

Are you really shocked that someone would make a backup before doing something they are unsure of?

Personally, I git clone a fresh copy to do any advanced stuff in, and sometimes an extra just as a backup. Though that's not really much different than copying the folder. Especially if he has uncommitted files like IDE settings and whatnot he doesn't want to fix if things go really bad.

> Are you really shocked that someone would make a backup before doing something they are unsure of?

No, but I'm shocked git is so misunderstood that this would be considered a time to do this.

Keeping a backup of previous versions is git's raison d'être. If you can't trust git to do this, how can you trust "cp" to make a copy of a file? I would love to get a genuine answer to my question: what do you think git is for and why do you use it? This would help me enormously to understand where you are coming from.

Git is a popular distributed versioning tool, but some commands have obscure syntax that is easy to get wrong, leading you into a mess that becomes a time drain. Creating a zip file of a git root folder takes seconds, and can get you out of the mess in seconds, rather than spending minutes or hours to undo some mess. If you can foresee git getting into a mess (and I can, after > 10 years of git experience), you can just take that backup to save time 'just in case' your git repo gets into that mess again.

Changing the git commit history (for example because you made a commit under the wrong name/email address) in particular can cause huge headaches.

Doing a git merge with tons of changes (think of clang-format white space changes in combination with various other commits) is another one.

This is not about the specific cases where your git repo can become a mess, but more about having a simple safety mechanism to always get you out of the mess.

> If you can't trust git to do this, how can you trust "cp" to make a copy of a file? I would love to get a genuine answer to my question: what do you think git is for and why do you use it? This would help me enormously to understand where you are coming from.

All of us - at some point - were new to git and coming from other VCS systems meant there was a relatively steep learning curve.

I also understand git fear - some of the stuff is a little arcane, and organizations are often very dogmatic and loud about their usage and approaches to git. It leads to a lot of gatekeeping. Do we rebase here? Do we never rebase? Linear history? Rebase feature branches or merge directly into main? It makes the fear of the tool that much stronger.

`cp`, on the other hand, is pretty straightforward. There are no local approaches to using it, there's no real `cp` expert in-house at most places. It does what it says on the box without a lot of frills or options.

git is a complex tool. It becomes easier the longer you use it, like most things, but it can be very intimidating to new or intermediate users.

> All of us - at some point - were new to git and coming from other VCS systems meant there was a relatively steep learning curve.

He's not new to it. He says he's been using it for over 10 years!

> No, but I'm shocked git is so misunderstood that this would be considered a time to do this.

You shouldn't be. As you say, you shouldn't need to do this, but the fact that so many people do feel the need to do this speaks to poor UI design on git's part. There are, I think, two main reasons why people feel the need to do this.

The first is that git makes it really easy to rewrite history, without really offering much in the way of safety rails. You have but to be burned by this once to lose all trust in git whatsoever. And this is something where there are safer ways to rewrite history: Mercurial's concept of phases or changeset evolution is easily far better than git in this regard. Even exporting the excised revisions as a revset ("strip-backup") is far easier for me to undo than having to go into git reflog (especially because I don't need to race any `git gc` command--note that git is the only VCS that feels the need to have a garbage collector!).

The second issue is that git has a lot of different places where state can be hiding, and it quickly becomes unclear which of the various places a command is affecting. Is this going to update my working directory, the most recent commit, the staging area, or multiple of those copies? If I'm in the middle of an interactive rebase, do I need to `git commit` or `git commit --amend` or some other command to properly update "the" commit? Maybe if you're fluent in git, it's all obvious, but if you're not fluent, it's way too easy to accidentally do the wrong thing. And looking up git documentation doesn't help--it's the only tool I regularly use where reading the documentation actively leaves me more confused than before I consulted it.

> The first is that git makes it really easy to rewrite history, without really offering much in the way of safety rails

It does, I just think they are not obvious enough because people haven't read an article like the one posted here.

Git is an append-only data store. You can't lose anything as long as you have committed it. Rebasing does rewrite history, but it doesn't delete the old history. It's still there. The reflog links to it. The old remote tracking branch links to it. You could even leave a tag there to link to it. There are many ways to get back.

Combining a small repertoire of git commands and this type of brute-force backup allows people to use git without having to learning all the details of its inner workings (or at least not having to keep that knowledge in everyday short-term memory.)

If a small repertoire of git commands covers 95% of what a person needs git for, and recovering from backup covers the remaining 5%, why spend time and effort "git-ifying" that last 5%?

It's entirely possible to trust something to work one way (e.g. keep a trivially restorable backup of previous state) when you do one thing with it and not trust it to do the same thing when you do another thing with it (especially if it's something you do infrequently or have never done before). The advantage of cp compared to git is that it only does one thing (more or less), so you don't have the potential for "doing things you're unsure of" in the same way as git.

Backups and version history are not the same thing. Especially when you're messing with the version history. I make copies when I'm using git-filter-repo, or BFG. But even rebase is a destructive action that would be nice to have a safety net for.

In the real world people have a ton of untracked files for their development environment, and uncommitted changes, but need an update from a coworkers branch that has a conflict with development, and a different conflict with your local changes. This can leave you in a weird state pretty quickly, and merge conflicts are a pain, especially if the conflicts are in a part of the code you're not very familiar with. Personally, I go full cowboy and work my way through it, but I am not surprised in the least when I hear that people make a backup so they can quickly restore.

One benefit of copying a directory instead of using git is that it will copy all of your untracked files, and uncommitted changes as is. Another benefit is that it works the same no matter what tooling you're using. I believe that some legacy code at my company is still on SVN and source safe. I also use open source projects that are developed with mercurial, bazaar, and fossil. If I were going to work on any of them, I would definitely be making backups the standard way instead of trusting my ability to use the tool properly.

> Could you tell me what you think git is for and why you use it?

Maybe it's not your intent, but you're coming off as a bit of a git yourself. He lacks your confidence.

> He lacks your confidence.

But why? I'm trying to learn here. I'm know I'm autistic and don't understand anyone. It's clear that there's a huge difference in how I perceive git versus how a lot of people apparently perceive it. I'm trying to understand how other people perceive it but nobody will tell me!

Reply on news.ycombinator.com