Automatically delete branches containing accepted patches?

Hi,

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?

Thanks,
Lars

On Sun, Aug 27, 2017 at 11:44 AM, Lars Schneider
[off-list ref] wrote:

Hi,

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?

Thanks,
Lars

You might be able to use patch-ids and git-cherry, to see if similar
patches (those with identical patch ids) are upstream. The patch id is
only calculated from the diff I believe, so it's mostly stable at
least as long as the contents didn't need to be changed to apply
upstream. It's not 100% perfect, but it might help with what you're
after?

Thanks,
Jake

You could rebase your branches onto the upstream branch.
Once all the patches are in, the SHA1 of the rebased branch is somewhere in the history of the upstream master.

I use a set of scripts I've written to handle multiple branches:
https://github.com/nmorey/git-topic-branches

Using namesapce it knows which branch is against which ref. You can autorebase everythinmg. It'll tell you once everything is merged upstream:
$ git auto-rebase  # alias for branch-autorebase
REBASING: dev/cbuild-cleanup on origin/master
REBASING FAILURE: dev/cbuild-cleanup on origin/master
REBASING: dev/cbuild-return-code on origin/master
REBASING: dev/suse-spec2 on origin/master
INTEGRATED UPSTREAM: dev/suse-spec2 just made it into origin/master
REBASING: dev/udev.md on origin/master
INTEGRATED UPSTREAM: dev/udev.md just made it into origin/master

You should be able to either hook up something for auto deletion, or use the few helpers to detect the merged ones and delete them


Le 27/08/2017 à 20:44, Lars Schneider a écrit :

Hi,

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?

Thanks,
Lars

On Sun, Aug 27, 2017 at 11:44 AM, Lars Schneider
[off-list ref] wrote:

Hi,

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?

As soon as my patches are picked up, I rename my internal branch to
be the same as its remote counter part. Usually I rebase my local
branches on these remote branches, such that directly after queuing
they are identical.

Usually I delete (local) branches as soon as I am either confident
they go in as is or they are not very interesting to me.
(e.g. a one off typo fix is developed on detached HEAD, sent out
and I forget about it. In case a discussion ensues, I have to either
take my patch or redo it. There is no local reminder of these things
in the form of a branch)

Stefan

Thanks,
Lars

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
scripts/tricks:

 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.

-Peff