All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Clemens Buchacher <drizzd@aon.at>,
	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, 10 Jul 2010 14:57:35 -0700 (PDT)	[thread overview]
Message-ID: <m3lj9jknlr.fsf@localhost.localdomain> (raw)
In-Reply-To: <20100710214050.GA3680@burratino>

Jonathan Nieder <jrnieder@gmail.com> writes:
> Clemens Buchacher wrote:
> 
> >          Maybe the real solution is a reflog for deleted branch
> > heads, rather than being too careful about whether or not a branch
> > can be deleted.
> 
> Yes, I think so.  Would there be any bad side effects to this?
> 
> diff --git a/refs.c b/refs.c
> index b540067..7ed0154 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -1084,7 +1084,6 @@ int delete_ref(const char *refname, const unsigned char *sha1, int delopt)
>  	 */
>  	ret |= repack_without_ref(refname);
>  
> -	unlink_or_warn(git_path("logs/%s", lock->ref_name));
>  	invalidate_cached_refs();
>  	unlock_ref(lock);
>  	return ret;

It's unfortunately not so easy.  The problem you have to solve is D/F
conflict: if you have 'foo/bar' branch, you can't create 'foo' branch,
but after deleting 'foo/bar' you want to be able to create 'foo'
branch and reflog for 'foo' branch.

Therefore there were ideas for various "Attic"-like areas for reflogs
for deleted branches...

-- 
Jakub Narebski
Poland
ShadeHawk on #git

  reply	other threads:[~2010-07-10 21:57 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 [this message]
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
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=m3lj9jknlr.fsf@localhost.localdomain \
    --to=jnareb@gmail.com \
    --cc=drizzd@aon.at \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.