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

From: Avery Pennarun <apenwarr@gmail.com>
Date: Jun 24, 2008, 05:20 UTC
Message-ID: <32541b130806232220r292d691cn5bf5f9976126aa29@mail.gmail.com>
In-Reply-To: <1978205964779154253@unknownmsgid>

On 6/24/08, David Jeske <jeske@google.com> wrote:

Show 12 quoted lines

> 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