On Mon, Dec 25, 2017 at 05:47:55PM -0800, Jacob Keller wrote:
> On Mon, Dec 25, 2017 at 5:16 PM, Carl Baldwin <carl@xxxxxxxxxxxxx> wrote:
> > Anyway, now I am compelled to use github which is also a fine tool and I
> > appreciate all of the work that has gone into it. About 80% of the time,
> > I rebase and force push to my branch to update a pull request. I've come
> > to like the end product of the rebase workflow. However, github doesn't
> > excel at this approach. For one, it doesn't preserve older revisions
> > which were already reviewed which makes it is difficult for reviewers to
> > pick up where they left off the last time. If it preserved them, as
> > gerrit does, the reviewer can compare a new revision with the most
> > recent older revision they reviewed to see just what has been addressed
> > since then.
>
> A bit of a tangent here, but a thought I didn't wanna lose: In the
> general case where a patch was rebased and the original parent pointer
> was changed, it is actually quite hard to show a diff of what changed
> between versions.
>
> The best I've found is to do something like a 4-way --cc merge diff,
> which mostly works, but has a few awkward cases, and ends up usually
> showing double ++ and -- notation.
>
> Just something I've thought about a fair bit, trying to come up with
> some good way to show "what changed between A1 and A2, but ignore all
> changes between parent P1 and P2 which you don't care that much about
> in this context.
I ran into this all the time with gerrit. I wrote a script that you'd
run on a working copy (with no local changes). I'd fetch and checkout
the latest patchset that I want to review(say, for example, its patchset
5) from gerrit. Then, say I wanted to compare it with patch set 3 which
has a different parent. I'd run this from the top level of my working
copy.
compare-to-previous-patchset 3
It would fetch patch set 3 from gerrit, rebase it to the same parent as
the current patch set on a detached HEAD and then git diff it with the
current patch set. If there were conflicts, it would just commit the
conflict markers to the commit. There is no attempt to resolve the
conflicts. The script was crude but it helped me out many times and it
was nice to be able to review how conflicts were resolved when those
came up.
Carl
PS In case you're curious, here's my script...
#!/bin/bash
remote=gerrit
previous_patchset=$1; shift
# Assumes we're sitting on the latest patch set.
new_patch_set_id=$(git rev-parse HEAD)
branch=$(git branch | awk '/^\*/ {print$2}')
[ "$branch" = "(no" ] && branch=
# set user, host, port, and project from git config
eval $(echo "$(git config remote.$remote.url)" |
sed 's,ssh://\(.*\)@\(.*\):\([[:digit:]]*\)/\(.*\).git,user=\1 host=\2 p<
gerrit() {
ssh $user@$host -p $port gerrit ${1+"$@"}
}
# Grabs a bunch of information from gerrit about the current patch
eval $(gerrit query --current-patch-set $new_patch_set_id |
awk '
BEGIN {mode="main"}
/ currentPatchSet:/ { mode="currentPatchSet" }
/ ref:/ { printf "new_patch_ref=%s\n", $2 }
/ number:/ {
if (mode=="main") {
printf "review_num=%s\n", $2
}
if (mode=="currentPatchSet") {
printf "new_patchset=%s\n", $2
}
}
')
# Fetch the old patch set
old_patch_ref=${new_patch_ref%$new_patchset}$previous_patchset
git fetch $remote $old_patch_ref && git checkout FETCH_HEAD
# Rebase the old patch set to the parent of the new patch set.
if ! git rebase HEAD^ --onto ${new_patch_set_id}^
then
git diff --name-only --diff-filter=U -z | xargs -0 git add
git rebase --continue
fi
previous_patchset_rebased=$(git rev-parse HEAD)
# Go back to the new patch set and diff it against the rebased old one.
if [ "$branch" ]
then
git checkout $branch
else
git checkout $new_patch_set_id
fi
git diff $previous_patchset_rebased
