From: Philip Oakley Date: Tue, 12 Dec 2017 16:57:47 GMT Subject: Re: Re: Re: bug deleting "unmerged" branch (2.12.3) Message-ID: In-Reply-To: <5A2E4480020000A1000293D8@gwsmtp1.uni-regensburg.de> From: "Ulrich Windl" > 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" schrieb am 08.12.2017 um 21:26 >>>> in > Nachricht <582105F8768F4DA6AF4EC82888F0BFBE@PhilipOakley>: >> From: "Ulrich Windl" >>> 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" 04.12.17 0.30 Uhr >>> >>> From: "Junio C Hamano" >>> > "Philip Oakley" 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) >