From: Jay Soffian <jaysoffian@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Yann Dirson <yann.dirson@bertin.fr>, git@vger.kernel.org
Subject: Re: ghost refs
Date: Tue, 20 Apr 2010 09:33:42 -0400 [thread overview]
Message-ID: <s2m76718491004200633la1cb07a6n8bc0d8d8e71b4e92@mail.gmail.com> (raw)
In-Reply-To: <20100420115124.GB22907@coredump.intra.peff.net>
On Tue, Apr 20, 2010 at 7:51 AM, Jeff King <peff@peff.net> wrote:
> Almost. The complication is that a branch "foo" prevents any branch
> "foo/bar" from being created. So if you leave the reflog in place, you
> are blocking the creation of the reflog for a new branch.
>
> So you need some solution to that problem. Things I thought of are:
>
> 1. Leave the reflog in place until such a foo/bar branch is created.
> [...]
> 2. Make a refs/dead hierarchy so that the reflogs don't interfere with
> [...]
> 3. Stick everything in a big "graveyard" reflog. I think there are
> [...]
4. Just append to the existing reflog? Given:
$ git checkout -b topic origin/master # 1
$ git add; git commit ...
$ git checkout master
$ git merge topic
$ git branch -d topic
$ git checkout -b topic origin/master # 2
Whose to say that the branch named topic from (1) and the branch named
topic from (2) are unrelated? Isn't the fact that they have the same
name is an indication that they are likely to be related. And even if
they are unrelated, what's wrong with re-using the same reflog?
Wouldn't it be obvious what happened? e.g.:
64c7587 topic@{0}: branch: Created from HEAD
abcdef3 topic@{1}: branch: deleted topic <---- I made this one up
3568c4b topic@{2}: commit: turned the knob to 11
707d9fb topic@{3}: branch: Created from HEAD
j.
next prev parent reply other threads:[~2010-04-20 13:33 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-07 16:38 ghost refs John Dlugosz
2010-04-07 16:58 ` Avery Pennarun
2010-04-07 21:00 ` Jeff King
2010-04-07 22:00 ` John Dlugosz
2010-04-07 22:03 ` Avery Pennarun
2010-04-07 22:10 ` John Dlugosz
2010-04-07 22:11 ` Avery Pennarun
2010-04-08 4:30 ` Jeff King
2010-04-08 16:07 ` John Dlugosz
2010-04-08 16:55 ` Junio C Hamano
2010-04-08 19:49 ` Jeff King
2010-04-08 20:42 ` Junio C Hamano
2010-04-08 22:14 ` Avery Pennarun
2010-04-08 23:04 ` Nicolas Sebrecht
2010-04-17 11:51 ` Jeff King
2010-04-17 16:32 ` Junio C Hamano
2010-04-17 16:57 ` Git documentation writing guidelines (was: Re: ghost refs) Jakub Narebski
2010-04-18 0:28 ` Git documentation writing guidelines Junio C Hamano
2010-04-19 15:33 ` ghost refs John Dlugosz
2010-04-20 7:02 ` Yann Dirson
2010-04-20 11:51 ` Jeff King
2010-04-20 12:02 ` Zefram
2010-04-20 13:00 ` Yann Dirson
2010-04-20 13:14 ` Zefram
2010-04-20 13:33 ` Jay Soffian [this message]
2010-04-20 14:24 ` Jeff King
2010-04-20 14:42 ` Yann Dirson
2010-04-20 14:52 ` Jay Soffian
2010-04-20 15:03 ` Alex Riesen
2010-04-20 15:10 ` Jeff King
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=s2m76718491004200633la1cb07a6n8bc0d8d8e71b4e92@mail.gmail.com \
--to=jaysoffian@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=yann.dirson@bertin.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).