Closed ojarjur closed 7 years ago
My current thinking of how to handle this is to add two optional fields to the request schema:
This would make the linkage bi-directional, so the rebase command would have to do the following under the hood:
The tool will also have to know to coalesce these requests into a single review. That probably just requires changes to the GetSummary
and ListAll
methods in the review
package. All operations should be performed on the latest continuation of a review.
Finally, since we want users to have their old commits garbage collected (if they so desire), we'll have to go with the approach of saying that the user is responsible for keeping those old commits around if they want them. However, we can make that easier to do by adding a flag to create a ref pointing at those commits. There are two options I can think of for doing this:
--tag/--no-tag
flags that control whether or not the rebase command adds a new tag pointing at the old review commits.Right now I'm leaning towards the first option, as it feels more "git idiomatic" to me, but it does have the consequence of polluting the tags namespace. A compromise might be to create tag-like refs outside of the "refs/tags/" namespace.
After thinking about this quite a bit more, I think the linkage from original commit to rebased-commit should be in one direction only; from the original commit to the rebased one(s).
In essence, what I am now leaning towards is keeping a single commit that is the anchor for all review metadata. This is consistent with how comments are always anchored at the first commit, even if they are about a subsequent commit.
This approach has the benefits of:
This has the downside of not failing as gracefully in the case that a user forgets to keep a pointer to their original commits (and they get garbage collected). This means that creating a ref pointing to the original history is more important.
As to that archival ref, I've started thinking that instead of this being a tag or a series of tags, that it can be a single ref (e.g. 'refs/devtools/archive') that can also be pushed/pulled by the git appraise push
and git appraise pull
commands. This would avoid us from polluting the tag namespace, and would also prevent the scenario that a user forgot to fetch the relevant archived commits from the remote repo.
This will be fixed by #63
Right now the
git appraise submit
command supports a--rebase
flag that will cause the review to be rebased onto the target branch as part of submitting it.That has the side effect of the code review data being disconnected from the final, submitted commit. As such, it is only sufficient if you want to use the code review data prior to the submit and not afterwards (for, e.g. browsing review history).
It would be better if the review data was connected to the rebased commit. We still want users to be able to have their intermediate commits garbage collected (if they so desire), so this linkage needs to be done in a way that does not force the intermediate commits to be kept (such as making them a parent of a notes commit).
Since there might be comments on intermediate commits that later get garbage collected, this also requires that the tool handle that scenario gracefully.
Additionally, we may want to add a
git appraise rebase
command that does this rebasing without submitting the review.