Web lists-archives.com

Re: Automatically delete branches containing accepted patches?

On Sun, Aug 27, 2017 at 08:44:06PM +0200, Lars Schneider wrote:

> I have lots of git/git branches and once in a while some patches make it 
> into git/git master. If this happens I would like to delete my branch
> with the patch automatically. That's not easily possible as the hashes 
> on my branches are, of course, not the same as the hashes on git/git.
> How do you deal with this situation? Do you manually delete your 
> branches or do you have some clever script to share?

It's definitely not a trivial problem.  I use a combination of three

 1. I have a script[1] that uses git-cherry to see what's made it to
    master or next. This isn't fool-proof, because sometimes minor
    tweaks mean that the patch-ids differ. But it catches most cases.

    [1] https://github.com/peff/git/blob/meta/merged

 2. I aggressively rebase all of my topics. Basically when I sit down to
    work each day, the first thing I run is a script[2] which
    just loops over each topic, rebasing each against its master.

    When topics have made it to master, this rebase produces an empty
    output, and the script from (1) shows them as merged. The tricky
    thing is that if a series touches the same area in multiple patches,
    rebasing it on itself will often end up with conflicts in the early
    patches. It's pretty easy to recognize this case and just "rebase
    --skip" past the already-applied patches.

    This also very occasionally results in a mis-merge where some little
    tidbit of a patch is left (e.g., if I added a new block but it ended
    up being moved elsewhere when Junio resolved a conflict, Git may
    mis-apply the patch and end up with a duplicate block. For C code
    this usually results in an error, but something like a duplicated
    test can often go unnoticed).

    [2] https://github.com/peff/git/blob/meta/rebase

 3. I have a small wrapper[3] around for-each-ref that shows me my
    topics in reverse authordate order. Reading it in that order reminds
    me of what should be in-flight and might need prodding. This can
    range from "it was merged and I need to delete the local branch" to
    "I sent it and it wasn't picked up for some reason" to "oops, I
    forgot to send it".

    The script's pretty short and I suspect most of it could be done
    with a "git branch --format" alias these days. The authordate
    sorting is very important for me because I have dozens of ancient
    crufty branches that are probably going nowhere but which I refuse
    to delete. ;)

    [3] https://github.com/peff/git/blob/meta/topics

So between the three of those, I generally eventually notice stale
branches lying around.