From: "Philip Oakley" <philipoakley@iee.org>
To: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
Cc: <git@vger.kernel.org>, <gitster@pobox.com>
Subject: Re: Re: bug deleting "unmerged" branch (2.12.3)
Date: Sat, 2 Dec 2017 20:56:44 -0000 [thread overview]
Message-ID: <7973FF5C21C64E6492828DD0B91F5AF7@PhilipOakley> (raw)
In-Reply-To: 5A1E70AA020000A100029175@gwsmtp1.uni-regensburg.de
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
To: <gitster@pobox.com>
Cc: <git@vger.kernel.org>
Sent: Wednesday, November 29, 2017 8:32 AM
Subject: Antw: 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?
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.
>
next prev parent reply other threads:[~2017-12-02 20:56 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 ` Antw: " Ulrich Windl
2017-12-02 20:56 ` Philip Oakley [this message]
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
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 \
--in-reply-to=7973FF5C21C64E6492828DD0B91F5AF7@PhilipOakley \
--to=philipoakley@iee.org \
--cc=Ulrich.Windl@rz.uni-regensburg.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://80x24.org/mirrors/git.git
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).