On Mon, Jun 19, 2017 at 05:46:22PM -0400, Paul Smith wrote:
> On Mon, 2017-06-19 at 23:33 +0200, Reda Lyazidi wrote:
> > with git I noticed when I removed a remote branch with git push origin
> > --delete
> > in my clone when I used git branch -a I don't the deleted branch
> > but my colleagues still see it.
> >
> > I tried with two clones in my PC, with the first one delete branch and
> > the other still sees it
> > despite git pull .
>
> Normally Git will not remove a remote's branch refs on a fetch (or
> pull) operation. This is a safety measure, since you might still have
> a use for that branch (for example to run diff against or similar).
>
> In order to remove branches that have been deleted in your remote, you
> must use the --prune (or -p) option to git fetch or git pull:
>
> git pull -p
>
> will get rid of them.
This is exactly correct. One further question, though, is "why does
git-push remove the branch?".
It makes sense that in general it tries to update the tracking branches
to match what we know we just sent to the other side. It's just
anticipating the next "git fetch". But it is a little funny that it
treats deletion differently than fetch would.
I don't recall that behavior being consciously decided. I could see an
argument for the current behavior: the danger is less because the branch
didn't just "go away" upstream, it was something the user in the local
repository did. But I could also see an argument for the other: the
point is to anticipate the next fetch, and it should behave exactly like
fetch.
I don't have a strong opinion either way.
I do hope that one day we would turn on "fetch --prune" by default, but
I'd prefer to see better safety for recovering deleted refs first (e.g.,
if we retained the reflog and you could access origin/deleted@{1}).
-Peff
