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

From: Jakub Narebski <jnareb@gmail.com>
Date: Jun 24, 2008, 09:39 UTC
Message-ID: <m3ej6nkw2u.fsf@localhost.localdomain>
In-Reply-To: <15381.9593288519$1214297235@news.gmane.org>

"David Jeske" <jeske@google.com> writes:

> This is mostly moot since I've understood that it's easy to set git
> to never GC. I guess I'm curious about why those GC fields would
> ever be set to anything other than never?

Because not everybody has unlimited quota / unlimited disk space? Besides growing repository, reflogs also grow even if you shitch between some limited set of commits.

Note however that IIRC reflogs are not enabled by default for bare repositories, and public repositories should be bare (without working directory). But see receive.denyNonFastForwards below.

Show 22 quoted lines

> -- Jeff King wrote:
> >
> > No. Git keeps the reachable DAG. So if the DAG is part of development
> > that is merged into one of your long running branches, or if you keep
> > around the branch that points to it, it will never go away.
> 
> Right, that's what I thought.
> 
> I'm not primarily concerned with what developers can do to their
> local git repositories. I'm concerned with what the default sync
> operations can let them do to the crown-jewels in the 'central
> organization repositories' which everyone is periodically pushing
> to.
> 
> I like that deleting a branch in your repo does not cause it to be
> deleted in other repos. Presumably in an organization we could
> prevent the central repo from ever accepting branch deletes from
> developers. (without some kind of authorization)
> 
> Does it have the same protection for all operations that can cause
> DAGs to be dangling? For example, if they branch -f" and push the
> branch?

git-config(1)

  receive.denyNonFastForwards::
        If set to true, git-receive-pack will deny a ref update which is
        not a fast forward. Use this to prevent such an update via a push,
        even if that push is forced. This configuration variable is
        set when initializing a shared repository.

That is even more than protection against leaving some commits dangling. This makes working on top of published branches safe.

If such all-or-nothing policy is not for you, you can always set-up hooks, like shown for example in contrib/hooks/update-paranoid

Or you can use different workflow, where maintainer _pulls_ from other developers or groups of developers, or apply (git-am) patches from email. This way if you screw up, it would be your fault for not having backups ;-)

[...]

> Quite a bit of my fear of losing data came from some issues in the
> git-gui. I'm trying out git on a windows project, and windows-shells
> just don't work right, so I'm using the "Git Gui". It turns out
> right-clicking on a history entry in the gui has no checkout option,

This might be result of the fact that in older versions of git you could not checkout arbitrary commit. You now can use so called "detached HEAD" (when current branch pointer points directly to the commit, instead of pointing to current branch [name]); note however that comitting on top of detached HEAD is discouraged.

Show 6 quoted lines

> and the only option it does have which will let you move the tree to
> that place is "reset --hard".. since this was the easiest thing to
> find in the GUI, I assumed it was the right way to do it, and then
> all my more recent changes disappeared. It doesn't seem to have
> reflog functionality, so I couldn't find any way to get back all my
> changes.

There is always ORIG_HEAD, which predates reflog introduction, and contains only old "version", as in

  $ git reset --hard ORIG_HEAD

That said, it would be nice if git-gui had some reflog interface.

> [...] The docs clearly explained that it
> will garbage collect dangling refs, and frankly the information
> about how often this happens is buried so deep I had no idea what
> the frequency was.

git-gc(1), section called (suprise, suprise) "Configuration".

-- 
Jakub Narebski
Poland
ShadeHawk on #git