bug deleting "unmerged" branch (2.12.3)

bug deleting "unmerged" branch (2.12.3)

[Ulrich Windl]

Hi!

During a rebase that turned out to be heavier than expected 8-( I decided to keep the old branch by creating a temporary branch name to the commit of the branch to rebase (which was still the old commit ID at that time).
When done rebasing, I attached a new name to the new (rebased) branch, deleted the old name (pointing at the same rebase commit), then recreated the old branch from the temporary branch name (created to remember the commit id).
When 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. Do you agree?

Regards,
Ulrich

Re: bug deleting "unmerged" branch (2.12.3)

[Johannes Schindelin]

Hi Ulrich,

On Tue, 28 Nov 2017, Ulrich Windl wrote:

> During a rebase that turned out to be heavier than expected 8-( I
> decided to keep the old branch by creating a temporary branch name to
> the commit of the branch to rebase (which was still the old commit ID at
> that time).
>
> When done rebasing, I attached a new name to the new (rebased) branch,
> deleted the old name (pointing at the same rebase commit), then
> recreated the old branch from the temporary branch name (created to
> remember the commit id).
>
> When I wanted to delete the temporary branch (which is of no use now), I
> got a message that the branch is unmerged.

This is actually as designed, at least for performance reasons (it is not
exactly cheap to figure out whether a given commit is contained in any
other branch).

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

No, respectfully disagree, because I have found myself with branches
pointing to the same commit, even if the branches served different
purposes. I really like the current behavior where you can delete a
branch with `git branch -d` as long as it is contained in its upstream
branch.

Ciao,
Johannes

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

[Ulrich Windl]

> Hi Ulrich,
> 
> On Tue, 28 Nov 2017, Ulrich Windl wrote:
> 
>> During a rebase that turned out to be heavier than expected 8-( I
>> decided to keep the old branch by creating a temporary branch name to
>> the commit of the branch to rebase (which was still the old commit ID at
>> that time).
>>
>> When done rebasing, I attached a new name to the new (rebased) branch,
>> deleted the old name (pointing at the same rebase commit), then
>> recreated the old branch from the temporary branch name (created to
>> remember the commit id).
>>
>> When I wanted to delete the temporary branch (which is of no use now), I
>> got a message that the branch is unmerged.
> 
> This is actually as designed, at least for performance reasons (it is not
> exactly cheap to figure out whether a given commit is contained in any
> other branch).
> 
>> 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?
> 
> No, respectfully disagree, because I have found myself with branches
> pointing to the same commit, even if the branches served different
> purposes. I really like the current behavior where you can delete a
> branch with `git branch -d` as long as it is contained in its upstream
> branch.

Hi!

I'm not talking about the intention of a branch, but of the state of a branch: If multiple branches point (not "contain") the same commit, they are equivalent (besides the name) at that moment. As no program can predict the future or the intentions of the user, it should be safe to delete the branch, because it can easily be recreated (from the remaining branches pointing to the same commit).

It shouldn't need a lot of computational power to find out when multiple branches point to the same commit.

Regards,
Ulrich

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

[Johannes Schindelin]

Hi Ulrich,

On Wed, 29 Nov 2017, Ulrich Windl wrote:

> > On Tue, 28 Nov 2017, Ulrich Windl wrote:
> > 
> >> During a rebase that turned out to be heavier than expected 8-( I
> >> decided to keep the old branch by creating a temporary branch name to
> >> the commit of the branch to rebase (which was still the old commit ID
> >> at that time).
> >>
> >> When done rebasing, I attached a new name to the new (rebased)
> >> branch, deleted the old name (pointing at the same rebase commit),
> >> then recreated the old branch from the temporary branch name (created
> >> to remember the commit id).
> >>
> >> When I wanted to delete the temporary branch (which is of no use
> >> now), I got a message that the branch is unmerged.
> > 
> > This is actually as designed, at least for performance reasons (it is
> > not exactly cheap to figure out whether a given commit is contained in
> > any other branch).
> > 
> >> 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?
> > 
> > No, respectfully disagree, because I have found myself with branches
> > pointing to the same commit, even if the branches served different
> > purposes. I really like the current behavior where you can delete a
> > branch with `git branch -d` as long as it is contained in its upstream
> > branch.
> 
> I'm not talking about the intention of a branch, but of the state of a
> branch: If multiple branches point (not "contain") the same commit, they
> are equivalent (besides the name) at that moment.

I did a poor job of explaining myself, please let me try again. I'll give
you one concrete example:

Recently, while working on some topic, I stumbled over a bug and committed
a bug fix, then committed that and branched off a new branch to remind
myself to rebase the bug fix and contribute it.

At that point, those branches were at the same revision, but distinctly
not equivalent (except in just one, very narrow sense of the word, which I
would argue is the wrong interpretation in this context).

Sadly, I was called away at that moment to take care of something
completely different. Even if I had not been, the worktree with the first
branch would still have been at that revision for a longer time, as I had
to try out a couple of changes before I could commit.

This is just one example where the idea backfires that you can safely
delete one of two branches that happen to point at the same commit at the
same time.

I am sure that you possess vivid enough of an imagination to come up with
plenty more examples where that is the case.

> As no program can predict the future or the intentions of the user, it
> should be safe to delete the branch, because it can easily be recreated
> (from the remaining branches pointing to the same commit).

Yes, no program can predict the future (at least *accurately*).

No, it is not safe to delete that branch. Especially if you take the
current paradigm of "it is safe to delete a branch if it is up-to-date
with, or at least fast-forwardable to, its upstream branch" into account.

And no, a branch cannot easily be recreated from the remaining branches in
the future, as branches can have different reflogs (and they are lost when
deleting the branch).

> It shouldn't need a lot of computational power to find out when multiple
> branches point to the same commit.

Sure, that test can even be scripted easily by using the `git for-each-ref
--points-at=<revision>` command.

By the way, if you are still convinced that my argument is flawed and that
it should be considered safe to delete a branch if any other branch points
to the same revision, I encourage you to work on a patch to make it so.

For maximum chance of getting included, you would want to guard this
behind a new config setting, say, branch.deleteRedundantIsSafe, parse it
here:

https://github.com/git/git/blob/v2.15.1/config.c#L1260-L1288

or here:

https://github.com/git/git/blob/v2.15.1/builtin/branch.c#L78-L97

document it here:

https://github.com/git/git/blob/v2.15.1/Documentation/git-branch.txt

and here:

https://github.com/git/git/blob/v2.15.1/Documentation/config.txt#L969

and handle it here:

https://github.com/git/git/blob/v2.15.1/builtin/branch.c#L185-L288

(look for the places where `force` is used, likely just before the call to
`check_branch_commit()`).

The way you'd want it to handle is most lilkely by imitating the
`--points-at` code here:
https://github.com/git/git/blob/v2.15.1/builtin/for-each-ref.c#L42

Ciao,
Johannes

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

[Philip Oakley]

Hi Ulrich

From: "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
To: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
Cc: <git@vger.kernel.org>
Sent: Wednesday, November 29, 2017 12:27 PM
Subject: Re: Antw: Re: bug deleting "unmerged" branch (2.12.3)


> Hi Ulrich,
>
> On Wed, 29 Nov 2017, Ulrich Windl wrote:
>
>> > On Tue, 28 Nov 2017, Ulrich Windl wrote:
>> >
>> >> During a rebase that turned out to be heavier than expected 8-( I
>> >> decided to keep the old branch by creating a temporary branch name to
>> >> the commit of the branch to rebase (which was still the old commit ID
>> >> at that time).
>> >>
>> >> When done rebasing, I attached a new name to the new (rebased)
>> >> branch, deleted the old name (pointing at the same rebase commit),
>> >> then recreated the old branch from the temporary branch name (created
>> >> to remember the commit id).
>> >>
>> >> When I wanted to delete the temporary branch (which is of no use
>> >> now), I got a message that the branch is unmerged.
>> >
>> > This is actually as designed, at least for performance reasons (it is
>> > not exactly cheap to figure out whether a given commit is contained in
>> > any other branch).
>> >
>> >> 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?
>> >
>> > No, respectfully disagree, because I have found myself with branches
>> > pointing to the same commit, even if the branches served different
>> > purposes. I really like the current behavior where you can delete a
>> > branch with `git branch -d` as long as it is contained in its upstream
>> > branch.
>>
>> I'm not talking about the intention of a branch, but of the state of a
>> branch: If multiple branches point (not "contain") the same commit, they
>> are equivalent (besides the name) at that moment.
>
> I did a poor job of explaining myself, please let me try again. I'll give
> you one concrete example:
>
> Recently, while working on some topic, I stumbled over a bug and committed
> a bug fix, then committed that and branched off a new branch to remind
> myself to rebase the bug fix and contribute it.
>
> At that point, those branches were at the same revision, but distinctly
> not equivalent (except in just one, very narrow sense of the word, which I
> would argue is the wrong interpretation in this context).
>
> Sadly, I was called away at that moment to take care of something
> completely different. Even if I had not been, the worktree with the first
> branch would still have been at that revision for a longer time, as I had
> to try out a couple of changes before I could commit.
>
> This is just one example where the idea backfires that you can safely
> delete one of two branches that happen to point at the same commit at the
> same time.
>
> I am sure that you possess vivid enough of an imagination to come up with
> plenty more examples where that is the case.
>
>> As no program can predict the future or the intentions of the user, it
>> should be safe to delete the branch, because it can easily be recreated
>> (from the remaining branches pointing to the same commit).
>
> Yes, no program can predict the future (at least *accurately*).
>
> No, it is not safe to delete that branch. Especially if you take the
> current paradigm of "it is safe to delete a branch if it is up-to-date
> with, or at least fast-forwardable to, its upstream branch" into account.
>
> And no, a branch cannot easily be recreated from the remaining branches in
> the future, as branches can have different reflogs (and they are lost when
> deleting the branch).
>
>> It shouldn't need a lot of computational power to find out when multiple
>> branches point to the same commit.
>
> Sure, that test can even be scripted easily by using the `git for-each-ref
> --points-at=<revision>` command.
>
> By the way, if you are still convinced that my argument is flawed and that
> it should be considered safe to delete a branch if any other branch points
> to the same revision, I encourage you to work on a patch to make it so.
>
> For maximum chance of getting included, you would want to guard this
> behind a new config setting, say, branch.deleteRedundantIsSafe, parse it
> here:
>
> https://github.com/git/git/blob/v2.15.1/config.c#L1260-L1288
>
> or here:
>
> https://github.com/git/git/blob/v2.15.1/builtin/branch.c#L78-L97
>

I'd agree that it is easy to misinterpret the message. After close reading 
of the thread, Junio put his finger on the scenario with:

-      "branch -d" protects branches that are yet to be merged to the 
**current** branch.   (my emphasis)

Maybe the error message could say that (what exactly was the error 
message?),
or the documenation be improved to clarify.


> document it here:
>
> https://github.com/git/git/blob/v2.15.1/Documentation/git-branch.txt
>
> and here:
>
> https://github.com/git/git/blob/v2.15.1/Documentation/config.txt#L969
>
> and handle it here:
>
> https://github.com/git/git/blob/v2.15.1/builtin/branch.c#L185-L288
>
> (look for the places where `force` is used, likely just before the call to
> `check_branch_commit()`).
>
> The way you'd want it to handle is most lilkely by imitating the
> `--points-at` code here:
> https://github.com/git/git/blob/v2.15.1/builtin/for-each-ref.c#L42
>
> Ciao,
> Johannes 

Re: bug deleting "unmerged" branch (2.12.3)

[Junio C Hamano]

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


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

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

[Ulrich Windl]

> "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?

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.

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

[Philip Oakley]

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

Re: bug deleting "unmerged" branch (2.12.3)

[Junio C Hamano]

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

Re: bug deleting "unmerged" branch (2.12.3)

[Philip Oakley]

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

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

[Ulrich Windl]

Hi Philip!

I'm unsure what you are asking for...

Ulrich
>>> "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

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

[Philip Oakley]

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

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

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

[Philip Oakley]

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