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.

  • How to use group file permissions correctly on a git repository?
  • understanding git cherry-pick
  • Error: Cannot pull with rebase: You have unstaged changes
  • GIT_EDITOR not working with macvim
  • Where are tag messages in Sourcetree
  • git: updating the current branch
  • Git, get unchaged files between commits
  • Accidentally reverted to master, lost uncommitted changes
  • Can Git really track the movement of a single function from 1 file to another? If so, how?
  • Tag a commit in Xcode
  • How can I make Gitolite post-receive hook to show full path to modified file?
  • Git CRLF changes showing up in git status
  • 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 <original@author.com>
    AuthorDate: Sun Aug 8 02:15:10 2010 -0300
    Commit:     New Committer <new@committer.com>
    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.