| 1 |
Hi, |
| 2 |
|
| 3 |
On Wed, May 27, 2020 at 02:45:29PM +0200, Toralf Förster wrote: |
| 4 |
> On 5/27/20 2:16 PM, Thomas Deutschmann wrote: |
| 5 |
> > The problem when doing review on Github |
| 6 |
> > for me is, that we usually create new revisions. Therefore we don't see |
| 7 |
> > what's changed in new revision versus previous revision. |
| 8 |
> 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 :-/ |
| 9 |
|
| 10 |
Indeed, on GitHub it is hard to review, but locally you can add |
| 11 |
|
| 12 |
[diff] |
| 13 |
algorithm = patience |
| 14 |
|
| 15 |
to your .gitconfig, and that should help with the diffs even when |
| 16 |
the revision changes by moving the file. When copying, it probably |
| 17 |
won't help. |
| 18 |
|
| 19 |
We could also try as a policy to split the revision bump from the |
| 20 |
changes, i.e. bump the revision in the first commit, then apply the |
| 21 |
changes in a second one. That way, one can click on the right commit |
| 22 |
to see the differences only, even on GitHub. Then we can squash when |
| 23 |
merging locally, since we don't click merge on GitHub anyway. |
| 24 |
|
| 25 |
Cheers, |
| 26 |
-Guilherme |
Archives