CODEWITHSUNDEEP
git
Rory Becker
Rory Becker

Reputation: 15701

How did I appear to lose data during a rebase?

The following is a short retelling of something that happened to me a few minutes ago. Everything is good. I have now found the code. I'm just wondering what I might have done wrong to reach this situation. I want to learn from this so I can avoid it again in the future.

FWIW: I have been doing some rebasing recently. I don't normally operate this way and I suspect the answer may lie in some poor rebasing. We'll see.

Discovery

So I just changed to a branch in which I remember performing some commits. Indeed the head commit is the one containing the changes I wanted. However my changes were not there!

Instead only some of the changes are there. :(

On closer examination I found that the remaining changes were deletes only. I figured just as you probably are, that I possibly didn't add all the changes prior to calling commit and that it's my own fault.

Update: The original commit should have contained some adds, some deletes and some modified files. This new "rebased" commit appeared only to have the deletes from what I was expecting.

Investigation

I had recently dropped a stash which I thought I'd no further need for. Perhaps my changes were in there?

I found this SO question which explained how I might identify all unreachable commits using...

gitk --all $( git fsck --no-reflog | awk '/dangling commit/ {print $3}' )

I managed to find several versions of the same commit (ie with the same commit message) created (alledgedly) at the same second

I figured this was understandable since they were likely copies generated during one or more rebase operations and had likely been given the original commit date.

So how is this possible?

This is where it gets interesting:

One of these commits was not like the others. One of these commits had all of my missing data.

And so my question is... How did I accomplish this? Did I rebase in a way which leaves half the available data behind?

Any clues\theories ?

Update: I've been asked in the comments about what steps I took to get here. The trouble is that's kind of the point of the question.

What could I have possibly have done to create 2 or more copies of a commit where the descriptions match but the content didn't?

I can make some suggestions about the pieces I might have used, but that's about it. I had been doing some simple rebasing. ie I visited a branch and executed:

git rebase master

I have also done some further investigation and have discovered that the correct commit is indeed the earliest. I have looked using gitK and the date next to the Author is always yesterday at 11:50:35. there is another date (the commit date) which appears to coincide with later rebases, but I swear I only used...

git rebase master

...from a given source branch

Upvotes: 3

Views: 234

Answers (2)

Philip Oakley
Philip Oakley

Reputation: 14071

There has been a recent discussion on the git list about rebase.

  1. It ignores merges by default
  2. It ignores anything that is already in the 'upstream'. The deletion may have already been done there.

The documentation for rebase has a number of 'asides' about behaviour hidden in the text that need careful reading.

Upvotes: 0

gcbenison
gcbenison

Reputation: 11963

Nitpicking by me and others aside, your question, which I think really amounts to (and I say this without malice) "where am I, and how did I get here?" is actually quite reasonable and comes up a lot when learning to work with git (and even for experienced git users, from time to time.) Fortunately, there is a git command designed to answer your exact question. It is:

git reflog

If you could post the output of that command (well, first 50 lines or so), much more informative answers could start showing up in this thread.

Upvotes: 2

Related Questions