1 |
On 27/05/2020 15:22, Guilherme Amadio wrote: |
2 |
> Hi, |
3 |
> |
4 |
> On Wed, May 27, 2020 at 02:45:29PM +0200, Toralf Förster wrote: |
5 |
>> On 5/27/20 2:16 PM, Thomas Deutschmann wrote: |
6 |
>>> The problem when doing review on Github |
7 |
>>> for me is, that we usually create new revisions. Therefore we don't see |
8 |
>>> what's changed in new revision versus previous revision. |
9 |
>> That's my main concern with the current behaviour: a "git diff" often doesn't show a diff against the previous (ebuild) file, it shows a diff against /dev/null :-/ |
10 |
> |
11 |
> Indeed, on GitHub it is hard to review, but locally you can add |
12 |
> |
13 |
> [diff] |
14 |
> algorithm = patience |
15 |
> |
16 |
> to your .gitconfig, and that should help with the diffs even when |
17 |
> the revision changes by moving the file. When copying, it probably |
18 |
> won't help. |
19 |
> |
20 |
> We could also try as a policy to split the revision bump from the |
21 |
> changes, i.e. bump the revision in the first commit, then apply the |
22 |
> changes in a second one. That way, one can click on the right commit |
23 |
> to see the differences only, even on GitHub. Then we can squash when |
24 |
> merging locally, since we don't click merge on GitHub anyway. |
25 |
> |
26 |
> Cheers, |
27 |
> -Guilherme |
28 |
> |
29 |
Hi, |
30 |
|
31 |
That looks like it could lead to errors when merging if the committer |
32 |
forgets to squash the two commits. |
33 |
|
34 |
Whether it is on GitHub or another platform, it is probably possible to |
35 |
have a bot compute the diff with the previous version every time a |
36 |
commit is pushed to a PR and add that as a comment. |