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

"David Jeske" [off-list ref] 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.

-- Jeff King wrote:

quoted

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.

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