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