Konstantin Hollerith <[email protected]> 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 neuerTestBranch
without 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
