On Tue, Apr 20, 2010 at 7:51 AM, Jeff King <peff@xxxxxxxx> 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.
--
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