Git log rebases

I know that GIT rebases will rewrite the history — i.e. the commit ids will change. However, Is there any way to trace when a branch was rebased and from which branch?

EDIT: I have a development branch ‘A’ and a topic branch ‘B’. ‘A’ is shared by the team. At some point, ‘A’ has been re-based with a mainstream branch. As a result of the re-base (and subsequent commits), when I updated the topic branch, I saw discrepancies. I am trying to find out the correct person to talk to to resolve the issues.

  • Workflow for small, rapid-changing and get-it-done-quickly projects
  • Rails 4 - capistrano 3 doesn't deploy last commits
  • Work-around for failing “git svn clone” (requiring full history)
  • git, SSH_ASKPASS on windows
  • GIT pull/fetch from specific tag
  • Git (TortoiseGit) - How to revert a single file to a previous revision and then undo the revert?
  • How does Git handle branches compared to SVN?
  • Problems cloning 1and1 git repository in 1and1 shared Linux server with Eclipse EGit
  • MSBuild and Jenkins: where to put credentials?
  • made a disastrous mistake with “create git repo here” .how to rectify/undo?
  • Why does git rebase --onto a b, git rebase --onto b a create a different SHA1 from the original?
  • git temporary unset of http.proxy
  • 3 Solutions collect form web for “Git log rebases”

    You can probably tell who did it! When you rebase, since the commits are rewritten, the committer information will be from the person doing the rebase, not the original author. (This is separate from the author information.)

    You can see this information in gitk (in the diff pane in the lower left) or in the output of git log --pretty=fuller (as in more full than full). Example log output:

    commit b8624718b97a39a04637c91ec3517c109f3f681d
    Author:     Original Author <>
    AuthorDate: Sun Aug 8 02:15:10 2010 -0300
    Commit:     New Committer <>
    CommitDate: Mon Jan 23 17:29:39 2012 -0800
        a lovely commit message

    The committer name, email, and date are from the operation that actually wrote the commit. Note that if it’s been rewritten multiple times, you’ll only have the most recent information.

    As for where it was rebased from… if the original version of the rebased commits are also in your history, that’s easy. Just search the full history for a matching commit, for example by a fragment of the commit message, or by something that was changed in the commit:

    git log --all --grep='commit subject from a rebased commit'
    git log --all -S'void this_function_was_added() {'

    If you don’t have the original commit anywhere in history anymore, that’s going to be tougher. Hopefully you’ll be able to find out by tracking down the person who did it, and if they don’t know, asking them to run git reflog show <branch> in their repository, to see the history of that branch.

    git reflog

    will allow you to look at the history of all your git workflow. On a project I’m working on, here are the top three reflog entries:

    151a1da HEAD@{0}: filter-branch: rewrite
    db8c822 HEAD@{1}: checkout: moving from fixes to master
    db8c822 HEAD@{2}: checkout: moving from master to fixes

    The first column shows the SHAID. So you can use the standard git commands on this SHAID
    e.g. git show 151a1da

    Reflog is a mechanism to record when the tip of branches are updated. This command is to manage the information recorded in it.

    “Basically every action you perform inside of Git where data is stored, you can find it inside of the reflog. Git tries really hard not to lose your data, so if for some reason you think it has, chances are you can dig it out using git reflog. What this means is that you can use it as a safety net: you shouldn’t be worried that a merge, rebase, or some other action will destroy your work since you can find it again using this command.”

    More on this subject in

    • this Git Ready post.
    • this StackOverflow question
    • The official Git reflog documentation
    Git Baby is a git and github fan, let's start git clone.