Re: Question about 'branch -d' safety

[Clemens Buchacher <drizzd@aon.at>]

[-- Attachment #1: Type: text/plain, Size: 4699 bytes --]

On Mon, Jul 19, 2010 at 11:06:23AM -0700, Junio C Hamano wrote:
> Clemens Buchacher <drizzd@aon.at> writes:
> 
> > + 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.

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]