From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
To: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
Subject: Antw: Re: bug deleting "unmerged" branch (2.12.3)
Date: Wed, 29 Nov 2017 09:09:11 +0100 [thread overview]
Message-ID: <5A1E6B27020000A10002916B@gwsmtp1.uni-regensburg.de> (raw)
> Hi Ulrich,
> On Tue, 28 Nov 2017, Ulrich Windl wrote:
>> During a rebase that turned out to be heavier than expected 8-( I
>> decided to keep the old branch by creating a temporary branch name to
>> the commit of the branch to rebase (which was still the old commit ID at
>> that time).
>> When done rebasing, I attached a new name to the new (rebased) branch,
>> deleted the old name (pointing at the same rebase commit), then
>> recreated the old branch from the temporary branch name (created to
>> remember the commit id).
>> When I wanted to delete the temporary branch (which is of no use now), I
>> got a message that the branch is unmerged.
> This is actually as designed, at least for performance reasons (it is not
> exactly cheap to figure out whether a given commit is contained in any
> other branch).
>> I think if more than one branches are pointing to the same commit, one
>> should be allowed to delete all but the last one without warning. Do you
> No, respectfully disagree, because I have found myself with branches
> pointing to the same commit, even if the branches served different
> purposes. I really like the current behavior where you can delete a
> branch with `git branch -d` as long as it is contained in its upstream
I'm not talking about the intention of a branch, but of the state of a branch: If multiple branches point (not "contain") the same commit, they are equivalent (besides the name) at that moment. As no program can predict the future or the intentions of the user, it should be safe to delete the branch, because it can easily be recreated (from the remaining branches pointing to the same commit).
It shouldn't need a lot of computational power to find out when multiple branches point to the same commit.
next prev parent reply other threads:[~2017-11-29 8:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-28 14:21 bug deleting "unmerged" branch (2.12.3) Ulrich Windl
2017-11-28 15:32 ` Johannes Schindelin
2017-11-29 8:09 ` Ulrich Windl [this message]
2017-11-29 12:27 ` Antw: " Johannes Schindelin
2017-12-02 20:52 ` Philip Oakley
2017-11-29 0:58 ` Junio C Hamano
2017-11-29 8:32 ` Antw: " Ulrich Windl
2017-12-02 20:56 ` Philip Oakley
2017-12-03 2:37 ` Junio C Hamano
2017-12-03 23:30 ` Philip Oakley
2017-12-04 15:57 ` Antw: " Ulrich Windl
2017-12-08 20:26 ` Philip Oakley
2017-12-11 8:40 ` Antw: " Ulrich Windl
2017-12-12 16:57 ` Philip Oakley
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).