From: Philip Oakley Date: Sat, 02 Dec 2017 20:56:51 GMT Subject: Re: Re: bug deleting "unmerged" branch (2.12.3) Message-ID: <7973FF5C21C64E6492828DD0B91F5AF7@PhilipOakley> In-Reply-To: <5A1E70AA020000A100029175@gwsmtp1.uni-regensburg.de> From: "Ulrich Windl" To: Cc: Sent: Wednesday, November 29, 2017 8:32 AM Subject: Antw: Re: bug deleting "unmerged" branch (2.12.3) > >> "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. > > 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? I think it was that currently you are on M, and neither A nor B are ancestors (i.e. merged) of M. As Junio said:- "branch -d" protects branches that are yet to be merged to the **current branch**. [I said the same in another part of the thread. The question now would be what needs changing? the error/warning message, the docs, something else?] > > 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. >