I'm not sure how we'd want to call the endpoint though? With an array of SHAs ([abc, def]), or with a range (abc..def). An array would leave us more flexibility for getting a set of changes, a range might save us some extra calls.
I'm not sure how we'd want to call the endpoint though? With an array of SHAs ([abc, def]), or with a range (abc..def). An array would leave us more flexibility for getting a set of changes, a range might save us some extra calls.
I think a range may be better, so that we don't have to pass along a potentially huge array of SHAs.
The command @jramsay suggested in https://gitlab.com/gitlab-org/gitlab-ce/issues/43281#note_148277111 would not give us paths that were touched in one commit but then had those changes reverted in a later commit. I think that's acceptable, since those files were ultimately not affected by the range of commits.
The command @jramsay suggested in https://gitlab.com/gitlab-org/gitlab-ce/issues/43281#note_148277111 would not give us paths that were touched in one commit but then had those changes reverted in a later commit. I think that's acceptable, since those files were ultimately not affected by the range of commits.
I was thinking doing git diff --name-only [range], but that would have the same effect. In the current implementation, where we loop over the diffs and get the paths those would be included. We should investigate if that difference is a problem.