joyent / grr Goto Github PK

grr is so useful for me that I hate having do things manually just because my CR has more than one issue. It would be very useful if grr could take a comma-separated list of issues and assembled them for me.

grr on a grr branch with local uncommited changes will include those changes in the patchset, then lose those uncommited changes

At least this is the understanding from what @joshwilsdon just hit. TODO: repro this. Perhaps grr could just error out if there are local uncommited changes.

i'm thinking something simple like grr -l inside a repo would output something like this:

$ grr -l
OS-1
OS-2
TOOLS-1

given

$ git branch | grep ' grr-'
  grr-OS-1
  grr-OS-2
  grr-TOOLS-1

So then I could do something like

$ grr -D OS-1

or even

$ grr -l | xargs -n1 grr -D

With a ssh prefix, grr gives me this:

grr: error: unexpected "cr" remote url: "ssh://[email protected]/joyent/sdc-docker.git (expected it to be "[email protected]:joyent/sdc-docker.git")

Note: ssh prefix is as described here:
https://github.com/joyent/joyent-gerrit/tree/master/docs/user#using-crjoyentus-with-an-existing-local-workspace

As seen in https://cr.joyent.us/#/c/6010/

I think what happened here is that patchset 2 had a parent 1df0262127ba10f20347daae7ac94c0d44fcd150

Then I rebased in Gerrit, and ran grr again. Because this then
rebased back to a previous parent, and modified the commit message,
I lost my CRs.

It would be great if grr could notice that the current patchsets parent is different
(an ancestor?) of the current local one, and refuse to upload by default.

How to reproduce

1. make change

2. submit cr

3. someone reviews

4. someone approves

5. Somewhere along the way, another change has already been merged upstream and now cannot fast-forward

6. Run...

    git checkout master
    git pull
    git checkout $oldbranch
    git rebase master
    grr
   

Note, that grr was not run between IA and rebasing. This causes gerrit to consider this a "non-trivial" change, and wipes out the reviews/aproval.

Somewhat the equivalent of this:

function cr-checkout {
    local crnum=$1
    if [[ -z "$crnum" ]]; then
        echo "cr-checkout: error: missing CRNUM argument" >&2
        echo "usage: cr-checkout CRNUM" >&2
        return 1
    fi
    patchset=$(git ls-remote cr | grep "refs/changes/../${crnum}/" | cut -d/ -f5 | sort -n | tail -1)
    git fetch -f cr refs/changes/${crnum:(-2)}/${crnum}/${patchset}:cr-${crnum}-${patchset}
    git checkout cr-${crnum}-${patchset}
}

You'd grr FULL-CR.JOYENT-US-URL and that would setup on a working feature branch with the latest patchset... inferring the issue from the current commit message. It should also be updatable if re-run after a new patchset was pushed.

If I already have a grr setup for a branch I'm working on, then I do 'git fetch' then pull --rebase into that branch, but I don't update my local master branch, then I end up with a Gerrit CR with all the intervenening changes I just pulled in. It'd be nice if grr could check for this and error out?

From joshw: I did grr -D grr-TRITON-717 and it deleted my grr-TRITON-809 branch. 🙂

That sucks.

It would be nice if grr automatically set the Gerrit topic to be the same as the main bug ID (and potentially over-ridable).