From: Karl Hasselström <kha@treskal.com>
Date: Mon, 26 May 2008 14:09:31 GMT
Subject: Re: [PATCH 3/3] Make old sha1 optional with git update-ref -d
Message-ID: <20080526140931.GA18440@diana.vm.bytemark.co.uk>
In-Reply-To: <alpine.DEB.1.00.0805261149310.30431@racer>

On 2008-05-26 11:51:12 +0100, Johannes Schindelin wrote:

> On Sun, 25 May 2008, Karl Hasselström wrote:
>
> > Giving the old sha1 is already optional when changing a ref, and
> > it's quite handy when running update-ref manually. So make it
> > optional for deleting a ref too.
>
> Isn't this a bit dangerous, especially given that there is
> potentially _no_ reflog as a safeguard?
>
> So no, it is not the same as when changing a ref.
>
> I am mildly negative on this (having lost some remote branches,
> because they were deleted _together with the reflogs_ by "git push
> bla :x"),

Deleting the wrong thing is never a fun experience. The thing is, this
patch doesn't really make it any easier to delete the wrong thing.
Before, you'd

  git update-ref -d <ref> <some-other-way-to-point-to-the-same-commit>

if you wanted to play it safe, and

  git update-ref -d <ref> <ref>

if you thought you knew what you were doing. All this patch does is
make the second usage mode easier to type.

(One might argue that a user who doesn't know what she's doing will
have an easier time shooting herself in the foot when the oldvalue is
optional, but I was under the impression that ease of use without
consulting the man page shouldn't be a factor when designing the
plumbing UI.)

I do agree with you that branch deletion is one of the more
"dangerous" operations in git. But I don't think making update-ref
hard to use is the answer there; what we'd really need is for old
reflogs to stay around for a while before being deleted.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle