From: Clemens Buchacher <drizzd@aon.at>
To: Jakub Narebski <jnareb@gmail.com>
Cc: Jonathan Nieder <jrnieder@gmail.com>,
git@vger.kernel.org, Nicolas Sebrecht <nicolas.s.dev@gmx.fr>,
Nanako Shiraishi <nanako3@lavabit.com>,
Junio C Hamano <gitster@pobox.com>
Subject: Re: Question about 'branch -d' safety
Date: Sat, 17 Jul 2010 11:30:06 +0200 [thread overview]
Message-ID: <20100717093006.GA11452@localhost> (raw)
In-Reply-To: <20100711133730.GA10338@localhost>
[-- Attachment #1: Type: text/plain, Size: 2513 bytes --]
Hi,
I am not sure how to proceed with this. It seems like there are
many arguments against it, and few for it. So in order to get a
better idea where we stand, I have summarized the arguments so far
below.
I do not know which solution would make everyone happy. But I think
there are a few advantages to be considered, and the remaining
issues are not insurmountable.
Clemens
---
Pros and cons for "undeleting branches":
+ safety net
It should not be easy to lose information with git. In most cases
branches can be restored from the HEAD reflog, but it can be
complicated if the branch has never been checked out. Even the
trivial case is not as obvious as searching for a "Branch deleted"
entry in the reflog.
+ 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. In
that sense, it cannot be considered safe any more. Being able to
restore deleted branches would make this a non-issue.
+ automatically prune remote tracking branches
Once it is easy to restore deleted branches, there is no need to
keep around remote tracking branches which have been deleted on the
remote. They can be pruned automatically on git fetch.
- only a convenience
Considering the many potential issues for this corner case, why
bother implementing it? Deleted branches can be restored from the
HEAD reflog anyways.
- implementation complexity
Due to the possibility of D/F conflicts, "deleted reflogs" have to
be renamed internally. This makes the reflog implementation more
complex.
- 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?
[1] Also, what happens if that new branch is renamed?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2010-07-17 9:30 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
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 [this message]
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=20100717093006.GA11452@localhost \
--to=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).