Re: why is git destructive by default? (i suggest it not be!)

["Avery Pennarun" <apenwarr@gmail.com>]

On 6/24/08, David Jeske <jeske@google.com> wrote:
> I moved a branch around and then deleted it, and I don't see any record in the
>  reflog of where it was, or that it ever was.
>
>  Am I missing something about how branches are used? I see some language in "git
>  tag" about how attempts are made to assure that others can't move around
>  semi-immutable tags during push, but I don't see any such language about
>  branches. What prevents someone from accidentally deleting an old branch that
>  nobody is watching, but is important to the history and then not noticing as gc
>  silently deletes the old deltas?
>
>  I've had need to pull out versions several years old multiple times in my
>  career, so this is the kind of thing I'm thinking about.

git branches are actually a very different concept from branches in,
say, subversion.

In subversion, a branch is normally created so that you can do
parallel development, and then you merge whole batches of changes
(with 'svn merge') from one branch into another.  When you do this,
you create a single new commit in the destination branch that contains
*all* the changes.  So if you want to look back in history to see who
did which part of the change for what reason, you have to go back to
the branch you merged *from*.  Thus, it's very important in subversion
that old branches never disappear.

git's philosophy is different.  Branches are really just "temporary
tags".  A merge operation doesn't just copy data from one branch to
another: it actually joins the two histories together, so you can then
trace back through the exact history of the merged branches, commit by
commit.  "git log" will show each checkin to *either* branch
individually, instead of just one big "merge" checkin.

The end result is that even if you delete the source branch after
doing a merge, nothing is actually lost.  Thus, there's no reason for
git to try to make branches impossible to lose, as they are in svn.
In the event that you really needed that branch pointer, it's in the
reflog, as a few people have pointed out.

Another way to think of it is that svn's concept of a "branch" is
actually the "reflog" in git.  (svn records which data a particular
branch name points to over time, just like git's reflog does.)  git
branches are something else entirely; a git branch always points at
only a single commit, and has no history of its own.

Does that help?  Perhaps it only confuses the issue :)

Have fun,

Avery