Re: Question about 'branch -d' safety

On Mon, Jul 19, 2010 at 11:06:23AM -0700, Junio C Hamano wrote:

Clemens Buchacher [off-list ref] writes:

quoted

+ less dependant on git branch -d

Since git branch -d deletes branches which have been merged to a
remote tracking branch, it does no longer guarantee that the branch
is still available in history locally, and if the branch is also
deleted remotely, running git remote prune removes it entirely.

Sorry, I have no idea what you are talking about in this paragraph.  I
cannot read "Who depends on git branch -d to achieve what" from your
description.  All I read in the above description is that what the command
does is a good thing.  If you want to keep the remote tracking branches
around, don't run "branch -d".  If you do want to remove the history of a
branch, run "branch -d".  Isn't it that simple?

So why do we have "branch -d" in the first place? Exactly because I
do _not_ want to reomve the history of a branch. I just want to
remove the reference to it, because it has already been merged and
is therefore of no interest any more.

Perhaps the missing "achieve what" may be that "output from 'git branch'
is too cluttered if I don't remove already merged branches as early as
possible, and forces me to run 'git branch -d' to clean things up too
often"?  If that is the issue you are trying to address, perhaps we can
solve that in a more direct way, e.g. "git branch --no-merged" easier to
access?

That would only delay the need for cleanup. And when I do the
cleanup, I have typically forgotten what the branch contains
exactly. So I like to use "branch -d" to find out if the branch
potentially contains something interesting, and get rid of it
immediately if it does not. If that does not work I have no choice
but to look at the branch before deleting it blindly.

And I used to consider both "branch -d" and "remote prune" to be
safe, because I knew that at some point I would have had to use
"branch -D" in order to actually lose history. Now this is not true
any more due to the scenario described above. In that sense,
"branch -d" is now pointless, because it's hardly safer than
"branch -D".

So this process is where a cannot depend on "branch -d" any more.

quoted

- user interface complexity

How to prune deleted branches? Currently, it is enough to do "git
branch -D branch; git gc --prune" in order to get rid of the branch
objects, at least if the HEAD reflog does not contain it or has
expired. Consider for example adding a remote, and removing it
again. This operation would leave a bunch of deleted branches,
which potentially occupy a lot of disk space.

How to find and restore deleted branches? If the reflog is used to
record deleted branches, and a new branch of the same name is
created, the reflog contains entries from unrelated branches. [1]
If the deleted reflogs are stored in an attic, how do we reference
those?

This is the area I am most concerned about.

Below you explain that we not need this feature, because we can do
backups instead. I disagree. But even if I were to agree, why are
you concerned about that? Even if you do not use the feature
personally, does it do any harm?

The effort necessary to permanently delete a branch (delete,
expire, prune) will stay exactly the same. The reflog syntax can
also stay the same. We only really need new commands to list and
recreate deleted branches.

If you take an analogy in say a file server implementation, yes, it should
not be easy to lose information there.  But it is and should be easy to
say "rm junk".  How would people recover from a mistake if they typed a > wrong filename, "rm junio" to lose a precious file "junio", when they
meant to lose "junk"?  They go to backups.

Backups are a good measure to protect against loss of large amounts
of data. They do not protect very well from an accidental "rm
junio", because that only works if junio was already in the latest
backup. Protecting against small-scale changes is exactly what a
version control system is good at. And they are much superior to
backups, because they keep history.

Can't git users do the same?
After all, .git directory is stored on a filesystem of some sort, and
taking a backup (you do take backups, don't you?) and picking the stuff
you lost from there should be a standard procedure that can be learned
outside of the context of git.

I usually use git for my more frequent backups. I put everything
that changes a lot and contains much personal work under version
control.

Clemens