On 27/05/2020 15:22, Guilherme Amadio wrote: > Hi, > > On Wed, May 27, 2020 at 02:45:29PM +0200, Toralf Förster wrote: >> On 5/27/20 2:16 PM, Thomas Deutschmann wrote: >>> The problem when doing review on Github >>> for me is, that we usually create new revisions. Therefore we don't see >>> what's changed in new revision versus previous revision. >> 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 :-/ > > Indeed, on GitHub it is hard to review, but locally you can add > > [diff] > algorithm = patience > > to your .gitconfig, and that should help with the diffs even when > the revision changes by moving the file. When copying, it probably > won't help. > > We could also try as a policy to split the revision bump from the > changes, i.e. bump the revision in the first commit, then apply the > changes in a second one. That way, one can click on the right commit > to see the differences only, even on GitHub. Then we can squash when > merging locally, since we don't click merge on GitHub anyway. > > Cheers, > -Guilherme > Hi,
That looks like it could lead to errors when merging if the committer forgets to squash the two commits. Whether it is on GitHub or another platform, it is probably possible to have a bot compute the diff with the previous version every time a commit is pushed to a PR and add that as a comment.
signature.asc
Description: OpenPGP digital signature
