> "Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> 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.
Hi!
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:
o---oA,B
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?
Regards,
Ulrich
>
>
> [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.
