On Mon, 19 Jul 2010, Will Palmer wrote:
> On Mon, 2010-07-19 at 11:16 -0600, Joshua Jensen wrote:
> > My brain has become muddied with all the ~2 stuff. Explain again why it
> > can't be as simple as this?
> ...snip...
> > git checkout -b integration HEAD@{1} (or 8000000)
> >
> > -Josh
>
> Because:
> 1) The HEAD reflog is the wrong place to stick things which weren't
> recently checked-out.
> and 2) the previous tip is currently the easiest-to-recover part of a
> deleted branch. What's lost is all the reflog data: order of states, and
> how they were reached.
>
> However, I /do/ think it's as simple as "don't delete the reflog right
> away when you delete a branch", and other edge-cases and niceties in
> terms of UI (such as ref renaming, resurrection of refs for tracking
> unrelated data, etc) can be taken care of later, if there's actually a
> need for them.
There are at least two issues, which are not niceties, but requirements:
1.) not deleting reflog for 'foo' when deleting 'foo' branch blocks
creating reflog for 'foo/bar' branch because of D/F conflict.
2.) there is issue of 'git branch -m bar foo', i.e. renaming some other
branch to 'foo', a branch which has its own reflog.
But you are right in that "moving reflog to attic" can be postponed till
needed.
--
Jakub Narebski
Poland
--
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