Re: [Bug report] git diff stat shows unrelated diff

From: Viresh Kumar <viresh.kumar@linaro.org>
Date: Feb 15, 2019, 06:40 UTC
Message-ID: <20190215064013.s7yfkmfvfmwfmepc@vireshk-i7>
In-Reply-To: <CABPp-BGstumw1eyZ++0itk-AR0Bk5zd0AchgznBpMq35a6ScUg@mail.gmail.com>

On 14-02-19, 13:23, Elijah Newren wrote:

Show 5 quoted lines

> I think you're getting tripped up by double-dot vs triple-dot with
> diff being different than log:
> 
> `git diff D..E` means the same thing as `git diff D E`, i.e. diff the
> two commits D and E.

Right, so both the branches have at least until rc2 (though pm/linux-next had until rc6), why will the diff D..E show the diff between rc1 and rc2 ?

> `git diff D...E` means the same thing as `git diff $(git merge-base D E) E`

I get exactly the same result with both .. and ... in this particular case and that's why I wonder if everything is okay or not.

The problem in this case is:
- PM tree had rc1,2,3,4,5,6 merged earlier into it.
- Then I got merged one of my branches which was based of rc1 into
  pm/linux-next.
- And now I am trying to send pull request for another branch which is
  a merge of the earlier branch (which got merged, based of rc1) and
  second branch that has more stuff over rc2.
- The most recent merge commit common between my branch and
  pm/linux-next becomes the earlier branch which was based of rc1.
- Now I expect ... to return the diff between rc1 and rc2 as it will
  diff against the most recent merge.
- But I expected ... to not include rc1..rc2 diff.

Show 10 quoted lines

> There are some people for whom this state of affairs makes sense.  I
> am not one of them, and I suspect you aren't either.  The arguments
> made by those who feel this makes sense seem reasonable to me in the
> moment when they present them, but I have never been able to remember
> these arguments longer than briefly.  It just doesn't stick with me.
> The only thing I seem to be able to retain is the following:  "git
> diff D..E is totally useless and should be an error because (1) it
> doesn't do what I expect and (2) for folks that want the behavior
> currently gotten with that syntax can instead just use a space instead
> of a double dot."

Okay but git request-pull uses .. and not ... and that's where I saw the issue in the first place.

-- 
viresh