git-review sync should probably detect if a branch is no longer needed and
delete it
just like the original hg plugin did. (One question is: should it check if
the branch has
unsubmitted changes?)

we shouldn't change git-review submit to do the clean up, because most
users won't
be able to use that subcommand.

Actually what I want is:

$ git start

which:

• throws me back to master
• runs git-review sync
• runs git-review cleanup (deletes submitted branches while it's at it)

... so then I have an easy way to start hacking & keeping things clean by default.

One could imagine extracting the generated Change-Id on a branch, and blow away the branch if that same Change-Id is on origin/master (or any other origin/xxx branch). That's slightly hazardous since you could have made local changes on that branch that you didn't get to pushing, and someone else may have submitted your change (or you did it from another computer). The safest might be to run git rebase @{u} on each branch, which will quietly drop the commit if it's been merged exactly (i.e. there were no diffs that weren't applied upstream).

git-review submit should probably delete the current branch and move back to master, regardless.

I have a Python script that checks whether each remote branch is fully merged into the currently checked-out branch and then can list those that have or, optionally, delete them from the remote repository. I don't know if this helps for the current situation, but it does help clean up a pile of stale branches every now and then.

https://gist.github.com/ShawnMilo/62770d9762ed51690e7a

I have a readonly client, in which I do nothing but git sync. When I need
a new client I cp -r it and work away on the copy. When done I rm -fr the
client. If I'm accumulating branches I'm doing it where they never bother
me.

On Thu, Dec 11, 2014 at 6:34 PM, Shawn Milochik notifications@github.com
wrote:

I have a Python script that checks whether each remote branch is fully
merged into the currently checked-out branch and then can list those that
have or, optionally, delete them from the remote repository. I don't know
if this helps for the current situation, but it does help clean up a pile
of stale branches every now and then.

https://gist.github.com/ShawnMilo/62770d9762ed51690e7a

—
Reply to this email directly or view it on GitHub
#9277 (comment).

I keep submitting via the gerrit web UI and then forgetting to change branch when I go to write my next CL. So far I have been recovering with

git stash
git checkout master
git stash pop

It would be great if running git sync on a branch with nothing other than a recently committed CL dropped be back in master and deleted the old branch.

FWIW, unless I'm misunderstanding, you don't have to stash your local changes in that situation if you haven't ran git review change yet (which if you did, it'd still be okay); you can just git checkout master and your unstaged files will follow you.

I find out I'm on the wrong branch when I run git change and it doesn't let me type in a new change description. Maybe I'm holding it wrong, but I keep doing it.

git submit should NOT switch you back to master. We tried that in hg submit on a release branch and it was very confusing.

For what it's worth, people who are doing just one thing at a time can actually use:

git change work
git add
git change # edit message
git mail
git submit
git sync
git add, git change, git mail, git submit, git sync
git add, git change, git mail, git submit, git sync
git add, git change, git mail, git submit, git sync
git add, git change, git mail, git submit, git sync

without ever moving off the work branch. That's a perfectly fine and supported workflow today. We shouldn't break it. (Here, "git submit" means click Submit in the UI. But adding "git submit" is on my list for today, and if we do that it can also do the "git sync", shortening the cycle to just "git add, git change, git mail, git submit, repeat")

git submit should NOT delete branches. If you do that, even the reflog is deleted, so there's no way (short of pawing through the git object store) to find the old work if you want it.

The same goes for git sync. It should NOT switch branches and NOT delete branches.

I don't object to 'git review cleanup'. I think 'git start' is probably a little too tied to Brad's workflow. Note that it's easy to write a git alias for that instead of baking it into git-review.

Note also that 'git pending' knows not to show branches with nothing there. I have that aliased to 'git p'.

I think my confusion was caused by starting on master, then trying to run git change. It recommends running git change branchname, and it was not clear to me branches are easily reusable, I assumed they needed to be recreated each time.

I have no UI suggestion to make this clearer, but maybe the fact that a work branch can be reused should be called out in the documentation. Right now http://golang.org/doc/contribute.html doesn't make it obvious.

Fwiw, I was under the same confusion that each cl should start a new
branch. I will add Russ' single branch process to the wiki.

You guys were confused because we only recently changed the tool to permit
branch reuse.
On Sat, 13 Dec 2014 at 06:24, Minux Ma notifications@github.com wrote:

Fwiw, I was under the same confusion that each cl should start a new
branch. I will add Russ' single branch process to the wiki.

—
Reply to this email directly or view it on GitHub
#9277 (comment).

I'm naively using git branch --merged | grep -v "\*" | xargs -n 1 git branch -d to prune stuff that's already in master.

If sync is not going to cleanup and jump back to the master, maybe you should rename the pending command. I'd suggest to have these two commands:

git review branches # lists the local branches with commit titles
git review prune    # cleans up the merged branches

I got impatient and wrote a little tool for this:

Install with:

  $ go get github.com/bradfitz/gitutil/git-cleanup

Use like:

  $ git checkout master
  $ git sync                # aka git codereview sync
  $ git cleanup