I lost my commits in Git and then I discovered about git reflog

Posted by sshetty03@reddit | programming | View on Reddit | 47 comments

I checked out an old commit to test something and ended up in a detached HEAD.
Made changes, committed, switched back, and suddenly my commits were gone.

That’s when I discovered git reflog.
It quietly tracks every move, even the ones you think you’ve lost.

wrote about the full recovery process in a short here -> https://medium.com/stackademic/what-is-detached-state-in-git-and-how-do-you-recover-from-it-eff10834e41f?sk=5f15731679de4a76209af7f419b57678

[-]

Sorry-Transition-908@reddit

I keep thinking it is re flog but it is ref log

[-]

memtiger@reddit

Hey, sometimes your repo needs a good flogging.

[-]

GraciaEtScientia@reddit

It fits the master/slave setup they had going before it became main.

[-]

tanaciousp@reddit

I think a dev introduced it to me as re-flog and now I can’t hear it in my brain as anything else.

[-]

baseballlover723@reddit

Same, though if I need to use the reflog, it does kinda feel like I've been flogged again as my ref counters keep going up as I try things.

[-]

Dragon_yum@reddit

The flogging will continue until you stop fucking ip your git

[-]

AvidCoco@reddit

Junior Developer discovers there’s more git commands than just commit and push.

[-]

tswaters@reddit

I lost my commits in git

Noo, that can't possibly be --

Then I discovered reflog

Ah, carry on!

[-]

ozyx7@reddit

git log --graph --reflog is far easier to understand than git reflog.

[-]

It's no wonder JJ (https://github.com/jj-vcs/jj) has been getting attention recently. Clearly, there is just no possibility to ever correct the obtuse flags for Git. You can either reflog or log --reflog... it doesn't feel like a serious suggestion and yet it is.

[-]

arcanemachined@reddit

There are many graphical frontends that will accomplish the same thing with git, e.g lazygit, magit, etc.

[-]

knightress_oxhide@reddit

nice, just added this as an alias

[-]

light24bulbs@reddit

alias "gitfuck"=

[-]

teerre@reddit

This whole thing is a great jujutsu ad. It really shows the main problem with git: it gives too much importance to something that is irrelevant: branches. The unit of work in git is obviously a commit, the idea of even talking about a "temporary commit" or "whoops I lost my commit" is crazy

[-]

janyk@reddit

The OP didn't RTFM and doesn't know how to git checkout -b testing_branch a93fdc6 and that means we need a whole new system with more manuals for OP to not read and fuck everything up?

If the OP is manually typing out a hash id like **a93fdc6** without specifying a human readable name anywhere, why would they be surprised that there's no human readable name to refer to in order to find their work later? Did they think it was automatically generated?

I'm not seeing any problem with git here that is wrong at such a fundamental level that it would require a rebuild from the ground up into a new system.

[-]

teerre@reddit

Do you have any doubt that not reading manual shouldn't mean you can easily "fuck up everything" in a version control system that only exists to prevent on you from "fucking up everything"?

The fact that OP and without-a-doubt countless others got into this conumdrum to begin with is the issue. OP isn't doing anything outrageous, they are obviously a beginner, and yet simple actions get you to a broken state. That's the problem in itself

[-]

janyk@reddit

There's no system where you can just do whatever you want without thinking and have it just work the way you want. There's always a minimum amount of effort and thought required to communicate your intentions to the language of the system. You can make it as clever as you want but there will always be a space where it is hard to differentiate actions as intentional or probable mistakes to be corrected or flagged. There is a responsibility on the user to communicate properly.

Ironically enough - or not so ironically - git did notify OP that they were in a probable mistaken detached HEAD state and he took the opportunity to figure out what that meant. So, on second thought, he did something right and studied it and figured out how to avoid it in the future. So kudos to him. But git also did the right thing.

I hope the OP learns to study his man pages a bit more to fill in other gaps in his mental model of version control.

[-]

teerre@reddit

That's just absurd. There are many systems that don't allow you to trivially make a catastrophic change. The very website you're using right now is one of them

Being a detached head isn't a problem

[-]

NotUniqueOrSpecial@reddit

There are many systems that don't allow you to trivially make a catastrophic change.

And maybe beginners should start with those, instead of a power-tool that was literally made to do this exact kind of surgery so that the kernel's history could be kept sane.

Fossil would be a great example of a system like that.

[-]

teerre@reddit

That only makes sense if the other system is somehow more powerful and therefore worth the danger. But that's not the case, git isn't easier nor more powerful than alternatives

[-]

NotUniqueOrSpecial@reddit

nor more powerful than alternatives

Ignorant shit like this drives me crazy; like, it takes literally 5s to check whether this is true before saying something this dumb.

Git has specific features that other VCSes don't (primarily around managing and rewriting history) that are critical to the healthy and sanity of the Linux kernel history and their ability to manage the contributions.

Like, Linus literally wrote it because the existing stuff didn't have that when he had to move off BitKeeper, and none of the other modern systems have added anything quite as powerful, specifically because it ends up being sharp edges that bite novice users.

[-]

teerre@reddit

Git is not more powerful than jujutsu, which is what we're discussing in this thread, in case you forgot

[-]

NotUniqueOrSpecial@reddit

No kidding? A VCS that's implemented in terms of other VCSes has many of the features of those VCSes?

You don't say?

Except for, you know:

A staging area (which, I will admit is a matter of taste)
Submodules
LFS
Hooks
Attributes
Partial clones
Shallow clones that can be deepened

[-]

teerre@reddit

A staging area is a terrible idea

These features are just porcelain. They'll be implemented when time allows. What we're discussing here are the core model of VC and that's where git isn't more powerful than jujutsu

[-]

NotUniqueOrSpecial@reddit

A staging area is a terrible idea

And an opinion is just that.

What we're discussing here are the core models of VC and that's where git isn't more powerful than jujutsu

Again, no kidding: it's literally git under the covers.

[-]

teerre@reddit

Not being able to lose your work is not an opinion, it's a fact

They are features, yes. Superficial features that will no doubt be implemented in jj. Again, we're discussing the core of the system, not peripheral features

[-]

zxyzyxz@reddit

Hence their initial comment, and suggestion to use jj.

[-]

NotUniqueOrSpecial@reddit

So, on second thought, he did something right and studied it and figured out how to avoid it in the future.

Makes me question what version of git they were on and when this message was added (which prints every time you do this, unless you disable it):

If you want to create a new branch to retain commits you create, you may do so (now or later) by using -c with the switch command. Example:

git switch -c <new-branch-name>

[-]

axonxorz@reddit

That message has been part of git for 14 years.

[-]

NotUniqueOrSpecial@reddit

Yeah, I was having a hard time remembering a time when it didn't print the whole thing, and that lines up.

So, point being, this entire thing was nonsense in the first place. Just another case of "user ignored the literal instructions they were handed at the exact moment they needed them".

Besides, you can tell from their shell entries that the story they tell isn't the actions they took.

They checked out headless, commited, and then switched back. Otherwise they'd never have needed the reflog at all (and obviously don't know about git checkout -, which I probably use almost more than commit.

[-]

yawara25@reddit

something that is irrelevant: branches.

What exactly do you mean by this?

[-]

teerre@reddit

Branches are just a name for a particular - well - branch of commits in your source tree. It's a tag. The actual important part of git are commits. But as OP shows, being outside a branch in git is somehow a bad thing, it forces you to think about the tag instead of the actual important commit

[-]

Scavenger53@reddit

battle royale push to master see who wins

[-]

Roang_zero1@reddit

Love me some jj undo

[-]

CichyK24@reddit

git reflog keeps a record of every action, and it can save you from losing work.

except it doesn't, and there are tons of git command which deletes local changes without possibility to recover (git restore, git clean, git reset --hard, etc.)

That's why jj or git-branchless has it's own undo commands.

Also this post is kinda weak. Weird style of writing, and basically says nothing new that wasn't told hundreds of times before. Who upvote this shit?

[-]