mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ulrich Windl" <>
To: <>
Cc: <>
Subject: Antw: Re: bug deleting "unmerged" branch (2.12.3)
Date: Wed, 29 Nov 2017 09:32:42 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

> "Ulrich Windl" <> writes:
>> 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 agree?
> That comes from a viewpoint that the only purpose "branch -d" exists
> in addition to "branch -D" is to protect objects from "gc".  Those
> who added the safety feature may have shared that view originally,
> but it turns out that it protects another important thing you are
> forgetting.
> Imagine that two topics, 'topicA' and 'topicB', were independently
> forked from 'master', and then later we wanted to add a feature that
> depends on these two topics.  Since the 'feature' forked, there may
> have been other developments, and we ended up in this topology:
>     ---o---o---o---o---o---M
>         \   \          
>          \   o---A---o---F
>           \         /  
>            o---o---o---o---B
> where A, B and F are the tips of 'topicA', 'topicB' and 'feature'
> branches right now [*1*].
> Now imagine we are on 'master' and just made 'topicB' graduate.  We
> would have this topology.
>     ---o---o---o---o---o---o---M
>         \   \                 /
>          \   o---A---o---F   /
>           \         /       /
>            o---o---o---o---B
> While we do have 'topicA' and 'feature' branches still in flight,
> we are done with 'topicB'.  Even though the tip of 'topicA' is
> reachable from the tip of 'feature', the fact that the branch points
> at 'A' is still relevant.  If we lose that information right now,
> we'd have to go find it when we (1) want to further enhance the
> topic by checking out and building on 'topicA', and (2) want to
> finally get 'topicA' graduate to 'master'.
> Because removal of a topic (in this case 'topicB') is often done
> after a merge of that topic is made into an integration branch,
> "branch -d" that protects branches that are yet to be merged to the
> current branch catches you if you said "branch -d topic{A,B}" (or
> other equivalent forms, most likely you'd have a script that spits
> out list of branches and feed it to "xargs branch -d").
> So, no, I do not agree.


I can follow your argumentation, but I fail to see that your branches A and B point to the same commit (which is what I was talking about). So my situation would be:


I still think I could safely remove either A or B, even when the branch (identified by the commit, not by the name) is unmerged. What did I miss?


> [Footnotes]
> *1* Since the 'feature' started developing, there were a few commits
>     added to 'topicB' but because the feature does not depend on
>     these enhancements to that topic, B is ahead of the commit that
>     was originally merged with the tip of 'topicA' to form the
>     'feature' branch.

  reply	other threads:[~2017-11-29  8:32 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   ` Antw: " Ulrich Windl
2017-11-29 12:27     ` Johannes Schindelin
2017-12-02 20:52       ` Philip Oakley
2017-11-29  0:58 ` Junio C Hamano
2017-11-29  8:32   ` Ulrich Windl [this message]
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

Reply instructions:

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:

* 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).