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@xxxxxxxxxxx
www.treskal.com/kalle
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
