On Wed, 20 May 2009, Wincent Colaiuta wrote:
> El 20/5/2009, a las 14:53, Nicolas Pitre escribió:
>
> > 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 I may have misinterpreted you; I understood that you said you wouldn't
> store intermediate index state after successive "git add" executions.
I wouldn't if those states don't discard data. If you 'git add foo' and
then 'git add bar' you don't lose anything. If you do two 'git add foo'
and the second one would discard the previous state of foo which is
different from the new one _then_ it is worth adding a reflog entry for
the otherwise about to be lost state.
Nicolas