git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Will Palmer <wmpalmer@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Clemens Buchacher <drizzd@aon.at>,
	Jakub Narebski <jnareb@gmail.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	git@vger.kernel.org, Nicolas Sebrecht <nicolas.s.dev@gmx.fr>,
	Nanako Shiraishi <nanako3@lavabit.com>
Subject: Re: Question about 'branch -d' safety
Date: Sun, 11 Jul 2010 23:02:55 +0100	[thread overview]
Message-ID: <1278885775.2308.27.camel@dreddbeard> (raw)
In-Reply-To: <7v1vb9hnd9.fsf@alter.siamese.dyndns.org>

On Sun, 2010-07-11 at 11:41 -0700, Junio C Hamano wrote:
> What problem are you guys really trying to solve?

Almost every porcelain git operation is, in general, "safe". Safety is
defined as "will not lose data". I tried to come up with a list of
"unsafe" commands recently, and others in #git pointed out that a lot of
commands could be made safe by inserting "wait 90 days" into various
points. Other than that, there's reset --hard. That's pretty damn safe,
in my opinion.

The reflog is the safety-net which allows us to give users help without
worrying about (as we might in other VCSs) someone typing a command
slightly wrong and blowing away their repository. "Don't worry, you
aren't going to break it" is a git truism which helps us to encourage
git newbies to experiment a little. Even history rewriting is a "safe"
operation.

Personally, I thought "git branch -d" was quite safe enough, as the HEAD
reflog would still have a copy of the tip, but as was pointed out to me,
this would only be there if the branch in question had been checked-out
recently, and of course the reflog for that branch would also be
destroyed. I don't really mind the second half of that, but if we're
going to solve one problem, why not solve both?

The main thing which is lost when a ref is deleted (assuming no gc,
which doesn't happen during a delete without anything else happening) is
the association between the various objects which will show up during
"git fsck" and the name of the ref which was deleted. Without that loss
of association the conversation can move from:
	"don't panic! If you haven't done anything else yet, you can type "git
fsck" and go through the list of dangling commits one by one until you
find it. Disable automatic garbage collection in the mean-time just to
be safe."

to (wishful thinking):
	"don't panic! try typing "git restore-ref -i" and select the branch you
deleted"


What's really problem I'm really trying to solve? I suppose part is the
"I want porcelain commands to be safe, at least for 30 days", and the
rest is that I like having more ways to have a conversation which starts
off in panic end with "oh, thanks! git is awesome!"

-- 
-- Will

  parent reply	other threads:[~2010-07-11 22:03 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-29 21:54 Question about 'branch -d' safety Nanako Shiraishi
2009-12-29 22:31 ` Nicolas Sebrecht
2009-12-30  3:12   ` Nanako Shiraishi
2009-12-30  6:43     ` Junio C Hamano
2009-12-30 21:08     ` Nicolas Sebrecht
2010-07-10  6:55     ` Clemens Buchacher
2010-07-10 21:40       ` Jonathan Nieder
2010-07-10 21:57         ` Jakub Narebski
2010-07-10 22:17           ` Jonathan Nieder
2010-07-11  6:55           ` Clemens Buchacher
2010-07-11  7:16             ` Jakub Narebski
2010-07-11  8:48               ` Julian Phillips
2010-07-11 13:37               ` Clemens Buchacher
2010-07-11 18:41                 ` Junio C Hamano
2010-07-11 19:05                   ` Jakub Narebski
2010-07-11 22:02                   ` Will Palmer [this message]
2010-07-12 18:47                   ` Clemens Buchacher
2010-07-12 23:50                     ` Junio C Hamano
2010-07-13  7:13                       ` Clemens Buchacher
2010-07-13  8:00                         ` Will Palmer
2010-07-13  8:30                           ` Johannes Sixt
2010-07-13  9:00                             ` Will Palmer
2010-07-13 22:21                           ` Clemens Buchacher
2010-07-17  9:30                 ` Clemens Buchacher
2010-07-18  0:43                   ` Jonathan Nieder
2010-07-18 11:55                     ` Jakub Narebski
2010-07-18 20:27                       ` Will Palmer
2010-07-18 23:19                         ` Jakub Narebski
2010-07-19  7:12                           ` Will Palmer
2010-07-19 11:01                             ` Jakub Narebski
2010-07-19 17:16                             ` Joshua Jensen
2010-07-19 19:34                               ` Clemens Buchacher
2010-07-19 19:45                               ` Will Palmer
2010-07-19 20:40                                 ` Jakub Narebski
2010-07-20  3:05                                 ` Joshua Jensen
2010-07-20  6:31                                   ` Will Palmer
2010-07-19 20:36                               ` Jakub Narebski
2010-07-19 18:06                   ` Junio C Hamano
2010-07-19 19:22                     ` Clemens Buchacher
2010-07-19 20:49                     ` Jakub Narebski
2010-07-20 13:19                     ` Ævar Arnfjörð Bjarmason
2010-07-20 13:34                       ` Matthieu Moy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1278885775.2308.27.camel@dreddbeard \
    --to=wmpalmer@gmail.com \
    --cc=drizzd@aon.at \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jnareb@gmail.com \
    --cc=jrnieder@gmail.com \
    --cc=nanako3@lavabit.com \
    --cc=nicolas.s.dev@gmx.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).