Re: [PATCH v3 0/3] branch: let --delete-merged find squash merged branches

[Junio C Hamano <gitster@pobox.com>]

Harald Nordgren <haraldnordgren@gmail.com> writes:

> So do we go with `--delete-irrelevant` or
> `--delete-irrelevant=squashed,rebased` to give us two levels here? I'd
> rather do the former.

Two comments.

* Naming

I would avoid a negative-sounding word like "irrelevant".  Your work
is almost always relevant, at least to you.

The purpose of the new feature is to find branches that the user no
longer needs to keep because they have been practically merged.
Perhaps --delete-integrated?  I do not know.  The naming matters,
and I hope somebody watching from the sidelines can suggest a better
alternative.

For lack of a better alternative that I can suggest, I will use
"--delete-foo" for the remainder of this message.

* Option value

Another point is that different kinds of detection should probably
form subset-superset relationships, rather than a Venn diagram, to
make them easy to understand and useful.

When you specify --delete-foo=squashed,rebased, do you expect that a
branch that would be removed by --delete-merged (i.e., merged as
identical commits) would be kept because it was not squash-merged
or rebased onto the upstream?  I doubt users would want to make such
a distinction.

I do not personally care about the distinction between rebasing and
squash-merging, but users probably do.  I suspect they expect that a
mode catching squash-merged branches would also recognize a branch
that was straight cherry-picked (or rebased) upstream.

Perhaps the options could be structured like this to be as easy to
understand as possible:

    --delete-foo=merged      Same as --delete-merged.
    --delete-foo=rebased     Above, plus rebased.
    --delete-foo=squashed    Above, plus squash-merged.

Would this be a clearer way to present the feature to users?

Thanks.