Search code examples
gitgit-loggit-reflog

Reference a the state of HEAD before the last `pull` or `merge`

I find that I often do this.

  • Run git pull or git pull --rebase

  • Look at the standard output to see the changes

    From github.com:foo/bar
   3d8749e..b795f99  master  -> origin/master

  • Copy ’n’ paste this version range to

    git log -p 3d8749e..b795f99

I wonder if there is is a way to specify “The state of HEAD before the last pull or merge“, so that I can simply always run the same command

git log -p HEAD@{before pull}..HEAD

Simply always using HEAD@{1} is close and might work for git pull, but not for git pull --rebase, because that adds multiple entries to the reflog:

$ git reflog
4111cc6 (HEAD -> master) HEAD@{0}: rebase finished: returning to refs/heads/master
4111cc6 (HEAD -> master) HEAD@{1}: pull --rebase: A local commit
b795f99 (origin/master, origin/HEAD) HEAD@{2}: pull --rebase: checkout b795f9924503c05da91b08e0e9ad3ffb48229bc8
d3379e5 HEAD@{3}: commit: A local commit
Solution

  • One alternative is to use the branch reflog. The HEAD reflog gets multiple entries during a rebase, but the branch reflog should just get one at the end. (Works in my tests, at least.) So it's not exactly "one command that's always the same", but 

    git diff master@{1}..master

    is closer to what you want.

    Another option is to use time-based reflog notation. For example, if you know that HEAD hasn't moved in the past, say, 5 minutes, then immediately after the rebase you could say

    git diff HEAD@{5.minutes.ago}..HEAD

    and as long as there was no weird slow-down of 5 minutes after the first update to HEAD, this should be ok. But of course if the rebase leads to conflict resolutions, there could be such a slow-down, and overall this is a half-baked solution that I mention only because it might usuall work with less variation between commands...

    You could make note of the system time just before the merge, and say

    git diff HEAD@{10:25:03}

    to avoid depending on the rebase timing. But now you're back to recording a value to plug into the command.

    [update - deleted an option I originally mentioned, because it doesn't really do the right thing; working with a cold today, head's a little fuzzy.]