git pull --rebase lost my commit

Question

I made a very small change to a file.

It was a single line that changed the following:

@@ -1,3 +1,3 @@
{
-  "cordova-cli": "5.2.0"
+  "cordova-cli": "5.4.1"
}

I committed the change and did a pull rebase

git add taco.json
git commit -m "updated the cordova cli version"
git pull --rebase

Now when I do a git log I do not see my change. Someone else made the exact same change in another commit. Did git recognize this and do away with my commit?

I still see it in git reflog.
I would have expected to get a merge conflict and not have my commit disappear entirely.

Here is the output from git log and git reflog:

git log --oneline
d8cb5c3 removed upload from gulp task
0ed5d5b updated analytics codeanalytics
901f724 minor style changes to search buttons


git reflog
d8cb5c3 HEAD@{0}: rebase finished: returning to refs/heads/dev
d8cb5c3 HEAD@{1}: pull --rebase: checkout d8cb5c341c7b08d6a9b43d89198171596d0c4234
f931b4e HEAD@{2}: commit: updated cordova cli version

Answer 1

In case your commit is exactly as another commit and make no changes (and no conflict of course), then yes. Git does not apply the commit as it does nothing.

Try 'cherry-pick' this commit and you will see the message:

nothing to commit, working directory clean
The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

git commit --allow-empty

During rebase, git show no message and simply drops the commit.

Answer 2

Conflict is a situation when there're different changes to the same line, but changes are the same - there's no conflict.

To have your commit in log you'll have to edit the other commit with change, but since it's already in upstream - it is not a good idea, because history rewriting involves a forced push and can lead to loss of work