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

[Philip Oakley]

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/5a1d70fd02a100029...@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)

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

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

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/5a1d70fd02a100029...@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)

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

[Philip Oakley]

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/5a1d70fd02a100029...@gwsmtp1.uni-regensburg.de/
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)

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

[Philip Oakley]

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.