Re: Why does 'git branch -d' act differntly after clone?
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Aug 20, 2015, 15:49 UTC
- Message-ID
- <xmqqa8tm7yez.fsf@gitster.dls.corp.google.com>
- In-Reply-To
- <CALwJaCzYgDKdcT7H7=5x0fnNRv4MsrtjJoHJcB9rJyh3dU--xQ@mail.gmail.com>
Konstantin Hollerith <khollerith@gmail.com> writes:
> Why does git branch -d acts differently after a clone?
In the former case, that branch is the only thing that knows about the commits near the tip of it. Immediately after you clone that repository, you have a copy of that branch as a remote-tracking branch for origin/neuerTestBranch. You didn't say how you got a local copy of it in there, but I'd imagine that in the clone you did something like:
$ git checkout neuerTestBranch
which is a short-hand for
$ git checkout -b neuerTestBranch origin/neuerTestBranch
and then went back to a branch other than that branch when you asked the branch to be removed, e.g.
$ git checkout master
$ git branch -d neuerTestBranchwithout building any further history on neuerTestBranch.
Now, your local neuerTestBranch is a mere unmodified copy of the remote-tracking branch origin/neuerTestBranch; the commits on the former will not become unreachable if you remove neuerTestBranch, because they are all reachable via origin/neuerTestBranch. And that is why the deletion of it has less severe potential of information lossage, compared to the original case where you attempt to remove the only copy.