Re: Re: bug deleting "unmerged" branch (2.12.3)

>
>> "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> 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.
>