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 |