Re: [PATCH v14 4/6] branch: add --prune-merged <branch>

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> writes:

> Phillip Wood <phillip.wood123@gmail.com> writes:
>
>> I was thinking that if I have feature1 with upstream origin/master and 
>> feature2 with upstream feautre1, then once feature1 is merged I'd still 
>> like "git log @{u}.." and "git rebase" without an explicit upstream to 
>> work when feature2 is checked out. If "git branch --prune-merged 
>> origin/master" deletes feautre1 then those commands stop working. Maybe 
>> it would be sensible to update feature2's upstream once feature1 is 
>> merged (which I think is what you're saying above) but do we really want 
>> to force the user to do that by deleting feature1?
>
> Ahh, reference with @{upstream}.  Yeah, that _does_ make sense.

Oops, hit [Send] too soon.

This reminds me of the discussion on a separate thread on "history
squash" and "history drop", that squashes a segment of history

    o---A---B---C

into a single commit (i.e., "We want to remove A and B and keep C" or
"We want to squash A, B, and C into a single commit")

    o---X

It is natural to consider "X" in the new history a counterpart of
"C" in the original history, but what should happen to refs that
used to point at A and B?  Sometimes it may make sense to drop the
refs that point into commits that disappear in the final history,
sometimes it may make sense to move them to point at the surviving
commit, sometimes it may make sense to leave them as-is (i.e., refs
still point at A and B in the old history, preventing them from
getting gc'ed).

And the safest behaviour would be to ask the user, i.e., notice that
we would get into this iffy situation and abort, asking the user
what to do.

Now that safest behaviour in the other topic translates to

 - Notice that a branch that is deleted (because it itself is
   merged) is still depended upon by being @{upstream} of somebody
   else, and when it happens, fail the operation (i.e., do not
   delete the branch).

What are the viable choices we can offer to the user in such a
situation?  I think there are a few viable choices.

 - Make the dependent branch no longer depend on anything.  Asking
   feature2@{upstream} would fail.

 - Move the @{upstream} of feature2 to the branch that "merged"
   feature1 and caused its removal.  Asking feature2@{upstream}
   would answer origin/master, which feature1 was removed after
   getting merged.

There may be others.  And there may be relationship similar to
feature1 vs feature2 that is not @{upstream} but something else that
makes a branch still "depend on" the other branch getting deleted.

Do we also need the same safety around "git branch -d feature1" by
the way?  The "-d" option with safety checks the same "is feature1
already merged (to its upstream)?" condition, so it can protect the
feature2 branch the same way, by saying either "oops, you cannot
delete feature1 because you still have other branches like feature2
that depend on it", or "ok, featur2 used to depend on feature1, but
because we are deleting feature1 based on it being in origin/master,
we will make feature2 depend on origin/master from now on".

Thanks.