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

> 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.

>
> 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)
>