Nicolas Pitre <nico@xxxxxxx> wrote:
> On Wed, 20 May 2009, Wincent Colaiuta wrote:
> > El 20/5/2009, a las 5:35, Nicolas Pitre escribi?:
> >
> > > Having a "trash" reflog would solve this unambiguously. That could also
> > > include your index example above. However, in the index case, I'd
> > > record a reflog entry only if you're about to discard a previously non
> > > committed entry. If you do:
> > >
> > > $ git add foo
> > > $ git add bar
> > > $ git commit
> > > $ hack hack hack
> > > $ git add foo
> > >
> > > then in this case there is nothing to be lost hence no additional entry
> > > in the "trash" reflog.
> >
> > That's true in the example you provide, but it doesn't really handle Jeff's
> > initial example ("git add" twice on the same file), where it is possible to
> > throw away intermediate state (by overwriting).
>
> Did I disagree with Jeff's original example?
No, but if you don't read closely enough to notice that the first
add affects path "foo" and the second add "bar", you might miss
what you were trying to say. I almost thought you disagreed with
Peff until I read your example a 2nd time. :-)
You did say "uncommitted entry causes reflog append", so in Peff's
original example of "git add a; vi a; git add a", we should be
creating a reflog entry for that first added state, which is clearly
not a disagreement.
FWIW, I think this is a great idea, but lack the time to code it
myself, otherwise I probably would start hacking on it right now.
--
Shawn.
--
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