From: "Philip Oakley" <philipoakley@iee.org>
To: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
Cc: <git@vger.kernel.org>
Subject: Re: Re: Re: bug deleting "unmerged" branch (2.12.3)
Date: Tue, 12 Dec 2017 16:57:39 -0000 [thread overview]
Message-ID: <FC22650D36BD4035925DCA978D52A912@PhilipOakley> (raw)
In-Reply-To: 5A2E4480020000A1000293D8@gwsmtp1.uni-regensburg.de
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
> Hi!
>
> Sorry for the late response:
> On a somewhat not-up-to date manual:
>
> -d, --delete
> Delete a branch. The branch must be fully merged in its upstream
> branch, or in HEAD if no upstream was set with --track or
> --set-upstream.
>
>
> Maybe the topic of multiple branches pointing to the same commit could be
> mentioned (regarding the status of each such branch being considered to be
> merged or not). Also "fully merged" could be made a bit more precise,
> maybe.
>
> Maybe gitglossary could have definitions for "merged" and "fully merged"
> with manual pages referring to it.
Thanks, I'll add your note to my list of clarifications.
Philip
>
> Regards,
> Ulrich
>
>
>>>> "Philip Oakley" <philipoakley@iee.org> schrieb am 08.12.2017 um 21:26
>>>> in
> Nachricht <582105F8768F4DA6AF4EC82888F0BFBE@PhilipOakley>:
>> From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
>>> Hi Philip!
>>>
>>> I'm unsure what you are asking for...
>>>
>>> Ulrich
>>
>> Hi Ulrich,
>>
>> I was doing a retrospective follow up (of the second kind [1]).
>>
>> In your initial email
>> https://public-inbox.org/git/5A1D70FD020000A100029137@gwsmtp1.uni-regensburg.d
>> e/
>> you said
>>
>> "I wanted to delete the temporary branch (which is of no use now), I got
>> a
>> message that the branch is unmerged.
>> 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."
>>
>> My retrospectives question was to find what what part of the
>> documentation
>> could be improved to assist fellow coders and Git users in gaining a
>> better
>> understanding here. I think it's an easy mistake [2] to make and that we
>> should try to make the man pages more assistive.
>>
>> I suspect that the description for the `git branch -d` needs a few more
>> words to clarify the 'merged/unmerged' issue for those who recieve the
>> warning message. Or maybe the git-glossary, etc. I tend to believe that
>> most
>> users will read some of the man pages, and would continue to do so if
>> they
>> are useful.
>>
>> I'd welcome any feedback or suggestions you could provide.
>> --
>> Philip
>>
>>> >>> "Philip Oakley" <philipoakley@iee.org> 04.12.17 0.30 Uhr >>>
>>> From: "Junio C Hamano" <gitster@pobox.com>
>>> > "Philip Oakley" <philipoakley@iee.org> writes:
>>> >
>>> >> 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**.
>>> >
>>> > Actually, I think people loosened this over time and removal of
>>> > branch X is not rejected even if the range HEAD..X is not empty, as
>>> > long as X is marked to integrate with/build on something else with
>>> > branch.X.{remote,merge} and the range X@{upstream}..X is empty.
>>> >
>>> > So the stress of "current branch" above you added is a bit of a
>>> > white lie.
>>>
>>> Ah, thanks. [I haven't had chance to check the code]
>>>
>>> The man page does say:
>>> . -d
>>> . Delete a branch. The branch must be fully merged in its upstream
>>> . branch, or in HEAD if no upstream was set with --track
>>> . or --set-upstream.
>>>
>>> It's whether or not Ulrich had joined the two aspects together, and if
>>> the
>>> doc was sufficient to help recognise the 'unmerged' issue. Ulrich?
>>> --
>>> Philip
>>>
>>>
>>
>> [1] Retrospective Second Directive, section 3.4.2 of (15th Ed) Agile
>> Processes in software engineering and extreme programming. ISBN
>> 1628251042
>> (for the perspective of the retrospective..)
>> [2] 'mistake' colloquial part of the error categories of slips lapses and
>> mistakes : Human Error, by Reason (James, prof) ISBN 0521314194
>> (worthwhile)
>
prev parent reply other threads:[~2017-12-12 16:57 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
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 [this message]
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=FC22650D36BD4035925DCA978D52A912@PhilipOakley \
--to=philipoakley@iee.org \
--cc=Ulrich.Windl@rz.uni-regensburg.de \
--cc=git@vger.kernel.org \
/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).