threads / discuss / 58336

`git range-diff` lists chunks with uninteresting changes

Subject: `git range-diff` lists chunks with uninteresting changes

## tl;dr

3 messages between Aug 20, 2022 and Aug 22, 2022.

replies: 2people: 2as markdown or json

squirrel· Aug 20, 2022, 14:51 UTC · lore

When someone makes a PR, they may be asked to rebase their feature branch onto main to resolve conflicts. It may be useful to quickly see what changed during the rebase, that is how the new version of PR is different to the old one.

If the PR branch has not been reparented, you may get away with `git diff`. But if it has, `git diff` may contain a lot of changes from upstream. Instead, `git range-diff` can be used.

The problem with this is that in this case `git range-diff` can show chunks with changes that have nothing to do with changes in the PR. Consider this repository (commands are runnable):

    git init
    git branch -m main
    echo -e "a\nb\nc\nd\ne\n1\n2\n3\nf" > file
    git add file
    git commit -am "a b c d e f"

    git checkout -b foo
    echo -e "a\nb\nc\nd\ne\n1\n2\n3\nfoo" > file
    git commit -am "f -> foo"

    git checkout main
    git checkout -b cat
    echo -e "a\nb\ncat\nd\ne\n1\n2\n3\nf" > file
    git commit -am "c -> cat"

We got a few letters of alphabet on separate lines on main, and in branch foo `f` is changed to `foo`, and in branch cat `c` is changed to `cat`.

    $ git log --all --graph --pretty=oneline
    * 90e873e3 (HEAD -> cat) c -> cat
    | * 3d8c1baf (foo) f -> foo
    |/
    * 4d2337dd (main) a b c d e f

Now, still on cat, let's combine the two changes.

    $ git rebase foo
    Successfully rebased and updated refs/heads/cat

    $ git log --all --graph --pretty=oneline
    * 98e554a0 (HEAD -> cat) c -> cat
    * 3d8c1baf (foo) f -> foo
    * 4d2337dd (main) a b c d e f

Now, `git rebase foo` worked automatically, so *the change* of the last commit on `cat` is the same as it was without rebase, which is changing `c` to `cat`. But if we run `git range-diff`, we will see this:

    $ git range-diff 90e873e3...cat
    -:  ------- > 1:  3d8c1ba f -> foo
    1:  90e873e ! 2:  98e554a c -> cat
        @@ file
         +cat
          d
          e
        - f
        + foo

It seems that this chunk is included for the sole reason that the change from `foo` is sort of close. If we try the same code, but put the lines `c` and `f` further apart, for example by replacing `e\n` with `e\n1\n2\n3\n` in the commands above, the output would be, as expected,

    $ git range-diff f1e0a6cc3...cat
    -:  ------- > 1:  4db06be f -> foo
    1:  f1e0a6c = 2:  cc56db7 c -> cat

I suggest not showing uninteresting chunks like that, or perhaps having a command line option that controls how close together the changes must be in order to be included in the output.

Johannes Schindelin· Aug 22, 2022, 16:02 UTC · re: squirrel · lore

Re: `git range-diff` lists chunks with uninteresting changes

Hi squirrel,

On Sat, 20 Aug 2022, squirrel wrote:

Show 72 quoted lines

> When someone makes a PR, they may be asked to rebase their feature branch onto
> main to resolve conflicts. It may be useful to quickly see what changed during
> the rebase, that is how the new version of PR is different to the old one.
>
> If the PR branch has not been reparented, you may get away with `git diff`.
> But if it has, `git diff` may contain a lot of changes from upstream. Instead,
> `git range-diff` can be used.
>
> The problem with this is that in this case `git range-diff` can show chunks
> with changes that have nothing to do with changes in the PR. Consider this
> repository (commands are runnable):
>
>     git init
>     git branch -m main
>     echo -e "a\nb\nc\nd\ne\n1\n2\n3\nf" > file
>     git add file
>     git commit -am "a b c d e f"
>
>     git checkout -b foo
>     echo -e "a\nb\nc\nd\ne\n1\n2\n3\nfoo" > file
>     git commit -am "f -> foo"
>
>     git checkout main
>     git checkout -b cat
>     echo -e "a\nb\ncat\nd\ne\n1\n2\n3\nf" > file
>     git commit -am "c -> cat"
>
> We got a few letters of alphabet on separate lines on main, and in branch
> foo `f` is changed to `foo`, and in branch cat `c` is changed to `cat`.
>
>     $ git log --all --graph --pretty=oneline
>     * 90e873e3 (HEAD -> cat) c -> cat
>     | * 3d8c1baf (foo) f -> foo
>     |/
>     * 4d2337dd (main) a b c d e f
>
> Now, still on cat, let's combine the two changes.
>
>     $ git rebase foo
>     Successfully rebased and updated refs/heads/cat
>
>     $ git log --all --graph --pretty=oneline
>     * 98e554a0 (HEAD -> cat) c -> cat
>     * 3d8c1baf (foo) f -> foo
>     * 4d2337dd (main) a b c d e f
>
> Now, `git rebase foo` worked automatically, so *the change* of the last commit
> on `cat` is the same as it was without rebase, which is changing `c` to `cat`.
> But if we run `git range-diff`, we will see this:
>
>     $ git range-diff 90e873e3...cat
>     -:  ------- > 1:  3d8c1ba f -> foo
>     1:  90e873e ! 2:  98e554a c -> cat
>         @@ file
>          +cat
>           d
>           e
>         - f
>         + foo
>
> It seems that this chunk is included for the sole reason that the change from
> `foo` is sort of close. If we try the same code, but put the lines `c` and `f`
> further apart, for example by replacing `e\n` with `e\n1\n2\n3\n` in the
> commands above, the output would be, as expected,
>
>     $ git range-diff f1e0a6cc3...cat
>     -:  ------- > 1:  4db06be f -> foo
>     1:  f1e0a6c = 2:  cc56db7 c -> cat
>
> I suggest not showing uninteresting chunks like that, or perhaps having a
> command line option that controls how close together the changes must be in
> order to be included in the output.

In a generic tool like `range-diff`, it is virtually guaranteed that the default operation does not satisfy all use cases. This example demonstrates that ;-)

In general, the `A...B` form does what users want, namely show you pairs between the "left" and the "right" commits in that symmetric range.

However, you _can_ use `range-diff` in a way that it produces what you want. In the example you provided above, `git range-diff foo cat@{1} cat` should do it. That would be the `<upstream> <before> <after>` form.

In general, you might need to play with `git merge-base --fork-point` (see *1* for more information). I could imagine that the following command might give you what you want in even more cases:

	git range-diff \
		$(git merge-base --fork-point @{u} @{1})..@{1} \
		$(git merge-base --fork-point @{u} HEAD)..HEAD

Ciao, Johannes

Footnote *1*: https://git-scm.com/docs/git-merge-base#_discussion_on_fork_point_mode

squirrel· Aug 22, 2022, 18:47 UTC · re: Johannes Schindelin · lore

Re: `git range-diff` lists chunks with uninteresting changes

Oh boy I messed up. There's a mistake in my reproduction example. Sorry!

I was saying that the uninteresting chunks pop if the changes from upstream appear close to changes in feature branch. To demonstrate the case when they are not close, I said to add a few lines, `1\n2\n3\n`, to the initial file. Somehow I managed to include this `1\n2\n3\n` in the main example that was supposed to demonstrate the issue. The correct, copy-pasteable, example:

    git init
    git branch -m main
    echo -e "a\nb\nc\nd\ne\nf" > file
    git add file
    git commit -am "a b c d e f"
    git checkout -b foo
    echo -e "a\nb\nc\nd\ne\nfoo" > file
    git commit -am "f -> foo"
    git checkout main
    git checkout -b cat
    echo -e "a\nb\ncat\nd\ne\nf" > file
    git commit -am "c -> cat"
    git rebase foo
    git range-diff foo cat@{1} cat

Now if I was to use the command that you give:

    $ git range-diff foo cat@{1} cat
    1:  5b1a2f5 ! 1:  16c4eea c -> cat
        @@ file
         +cat
          d
          e
        - f
        + foo

I think the command and the result are both correct. Indeed the change of `f` to `foo` is a difference between the two ranges. However, this change is just not interesting! I hope there's a way to not see it.

Sorry about the mess up.

On Mon, 22 Aug 2022 at 17:02, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 101 quoted lines

>
> Hi squirrel,
>
> On Sat, 20 Aug 2022, squirrel wrote:
>
> > When someone makes a PR, they may be asked to rebase their feature branch onto
> > main to resolve conflicts. It may be useful to quickly see what changed during
> > the rebase, that is how the new version of PR is different to the old one.
> >
> > If the PR branch has not been reparented, you may get away with `git diff`.
> > But if it has, `git diff` may contain a lot of changes from upstream. Instead,
> > `git range-diff` can be used.
> >
> > The problem with this is that in this case `git range-diff` can show chunks
> > with changes that have nothing to do with changes in the PR. Consider this
> > repository (commands are runnable):
> >
> >     git init
> >     git branch -m main
> >     echo -e "a\nb\nc\nd\ne\n1\n2\n3\nf" > file
> >     git add file
> >     git commit -am "a b c d e f"
> >
> >     git checkout -b foo
> >     echo -e "a\nb\nc\nd\ne\n1\n2\n3\nfoo" > file
> >     git commit -am "f -> foo"
> >
> >     git checkout main
> >     git checkout -b cat
> >     echo -e "a\nb\ncat\nd\ne\n1\n2\n3\nf" > file
> >     git commit -am "c -> cat"
> >
> > We got a few letters of alphabet on separate lines on main, and in branch
> > foo `f` is changed to `foo`, and in branch cat `c` is changed to `cat`.
> >
> >     $ git log --all --graph --pretty=oneline
> >     * 90e873e3 (HEAD -> cat) c -> cat
> >     | * 3d8c1baf (foo) f -> foo
> >     |/
> >     * 4d2337dd (main) a b c d e f
> >
> > Now, still on cat, let's combine the two changes.
> >
> >     $ git rebase foo
> >     Successfully rebased and updated refs/heads/cat
> >
> >     $ git log --all --graph --pretty=oneline
> >     * 98e554a0 (HEAD -> cat) c -> cat
> >     * 3d8c1baf (foo) f -> foo
> >     * 4d2337dd (main) a b c d e f
> >
> > Now, `git rebase foo` worked automatically, so *the change* of the last commit
> > on `cat` is the same as it was without rebase, which is changing `c` to `cat`.
> > But if we run `git range-diff`, we will see this:
> >
> >     $ git range-diff 90e873e3...cat
> >     -:  ------- > 1:  3d8c1ba f -> foo
> >     1:  90e873e ! 2:  98e554a c -> cat
> >         @@ file
> >          +cat
> >           d
> >           e
> >         - f
> >         + foo
> >
> > It seems that this chunk is included for the sole reason that the change from
> > `foo` is sort of close. If we try the same code, but put the lines `c` and `f`
> > further apart, for example by replacing `e\n` with `e\n1\n2\n3\n` in the
> > commands above, the output would be, as expected,
> >
> >     $ git range-diff f1e0a6cc3...cat
> >     -:  ------- > 1:  4db06be f -> foo
> >     1:  f1e0a6c = 2:  cc56db7 c -> cat
> >
> > I suggest not showing uninteresting chunks like that, or perhaps having a
> > command line option that controls how close together the changes must be in
> > order to be included in the output.
>
> In a generic tool like `range-diff`, it is virtually guaranteed that the
> default operation does not satisfy all use cases. This example
> demonstrates that ;-)
>
> In general, the `A...B` form does what users want, namely show you pairs
> between the "left" and the "right" commits in that symmetric range.
>
> However, you _can_ use `range-diff` in a way that it produces what you
> want. In the example you provided above, `git range-diff foo cat@{1} cat`
> should do it. That would be the `<upstream> <before> <after>` form.
>
> In general, you might need to play with `git merge-base --fork-point` (see
> *1* for more information). I could imagine that the following command
> might give you what you want in even more cases:
>
>         git range-diff \
>                 $(git merge-base --fork-point @{u} @{1})..@{1} \
>                 $(git merge-base --fork-point @{u} HEAD)..HEAD
>
> Ciao,
> Johagnnes
>
> Footnote *1*: https://git-scm.com/docs/git-merge-base#_discussion_on_fork_point_mode