1

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
Joachim Breitner
  • 25,395
  • 6
  • 78
  • 139
  • I think the diff between `HEAD@{before pull}..HEAD` is the same with `origin/master@{1}..origin/master@{0}`. Not sure if there's conflict. – ElpieKay Mar 15 '18 at 15:22
  • @ElpieKay : That would be the difference between the last two fetches of `master`, not the difference between the local branch before and after the most recent fetch. By which I mean, yes it often will be the same change, but definitely not in case of conflict and not necessarily exactly the same even with non-conflicting changes to the same file – Mark Adelsberger Mar 15 '18 at 15:37
  • @MarkAdelsberger Yes, you are right. I also missed cases in which a different branch is pulled. – ElpieKay Mar 15 '18 at 15:47

1 Answers1

4

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.]

Mark Adelsberger
  • 42,148
  • 4
  • 35
  • 52