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

[Jakub Narebski <jnareb@gmail.com>]

It looks like for some reason not all messages made it to git mailing
list, at least when using GMane to read git mailing list.  Strange...

"Avery Pennarun" <apenwarr@gmail.com> writes:
> 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.

Deleting branch (BTW. git prints warning when deleting branch can
result in [temporary] loss of [easy access to] some commits) deletes
its reflog[*1*], but you can still use HEAD reflog ("what was checked
out" reflog).

>> 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?

BTW. branches _deletions_ are not by default transferred (even if
using globbing refspecs, which is not default); you have to use 
"git remote prune <remote nick>" to remove remote-tracking branches
which track branches that got deleted on remote.

Besides nobody and nothing can fully protect you from your stupidity.
You can "accidentally" do 'rm -rf .git' for example :-/

>> 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.

The answer is: don't delete branches accidentally ;-).

Seriously, in any sane workflow you have several long lasting
branches, be it 'maint', 'master', 'next' or be it 'maintenance',
'stable'/'mainline'/'trunk', 'devel', into whose you merge in
[temporary, short lived] topic branches when topic is ready for
inclusion.  And you NEVER delete such branches (git can't protect you
from deletion any more than Linux can protect you if you do "rm -rf ~"). 

Any commit for whose there is parentage line from one of those
long-lived "development" branches would be protected from pruning
during git-gc run.

> 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".

I'd rather say thay branches (refs/heads branches) are "growth points"
of graph (diagram) of revisions (versions).  (This graph is called DAG
in git documentation, because it is Directed Acyclic Graph).

But it is true that in git branches are just _pointers_ to the DAG
of commits.  All data is kept in the content addressed object database
which is git repo storage, and parentage links are contained in commit
objects.

> 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.

Let me help explain that using some ASCII-art diagram.  You need to
use fixed-width (non-proportional) font to view it correctly.  Time
flows from the left to right.

Let's assume that we have the following state: some history on branch
'master': 

       object database              refs information
    /-------------------\        /---------------------\
   
     .<---.<---.<---A             <--- master <=== HEAD

For the commits the "<---" arrow means that commit on the right side
of arrow has commit on the left hand side of arrow as its parent
(saved in the multi-valued "parent" field in the commit object).  For
the references "<---" arrow means that branch master points to given
commit, and "<===" means symbolic reference, i.e. that ref points to
given branch (you can think of it as symlink, and it was some time ago
implemented as such).

Now assume that we created new branch 'test', and we have comitted
some revisions being on it:

     .<---.<---.<---A             <--- master
                     \
                      \-B<---C    <--- test     <=== HEAD

Let's assume that we, or somebody else, did some work on 'master'
branch (to not confuse you with the "fast-formward" issue):

     .<---.<---.<---A<---X<---Y    <--- master
                     \
                      \--B<---C    <--- test     <=== HEAD

Now we have finished feature which we tried to develop in 'test', so
we merge changes back to 'master':

     .<---.<---.<---A<---X<---Y<---M       <--- master <=== HEAD
                     \            /
                      \--B<---C<-/         <--- test

Note how merge commit 'M' has two parents.

Now if we were to delete branch 'test' now:

     .<---.<---.<---A<---X<---Y<---M       <--- master [<=== HEAD]
                     \            /
                      \--B<---C<-/

it is only pointer that gets deleted (and reflog[*1*]).  All commits
which were on this branch are 'reachable', so they never would get
deleted, even if [HEAD] reflog expires[*2*].

> 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.

s/in the reflog/in the HEAD reflog/.

See above for explanation with pictures (or if you want some graphics,
take a look at presentations linked from GitLinks page and/or
GitDocumentation page on git wiki, http://git.or.cz/gitwiki/).

HTH

Footnotes:
==========
[*1*] There was an effort to create some sort of 'Attic' / 'trash can'
for deleted reflogs, but I guess it got stalled.  There is techical
issue caused by the fact that reflogs are stored as files, and you can
have so caled file<->directory conflict, when you deleted branch
'foo', and created branch 'foo/bar'.

[*2*] You can always write "never" as time to expire, and it even
works now ;-)
-- 
Jakub Narebski
Poland
ShadeHawk on #git