Re: non-empty index with git commit -a

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 16, 2011 at 11:28:17AM +0100, Matthieu Moy wrote:

> Jeff King <peff@xxxxxxxx> writes:
> 
> > So? Your question was whether index state is precious. If it's precious,
> > shouldn't we be keeping a history of it?
> 
> If it's really precious, it probably means you should be commit
> --amend instead. You'd get the reflog, and essentially the same
> functionalities.

Yeah, that is good advice, and I do actually end up doing a lot of
intermediate commits and then either amending or sorting them out at the
end. And that helps with sorting out big changes.

But it does sort of feel like saying "we don't need a safety valve. You
just need to back up your work before doing anything dangerous". I have
to remember to do it. Which is fine if my workflow is
add-amend-add-amend. But maybe I have some half-saved index state and I
am about to try doing a merge checkout or stash apply.

Anyway, I'm not convinced it is all that precious (at least not enough
to merit working on the reflog). Yes, there have been times I've wished
I could go back to the index state of a minute ago, and had to re-sort
changes. But it usually doesn't take all that much time (thanks to "git
add -p"). My main objection is that I just don't see those cases as
different from "git commit -a". Either it is worth protecting, or it
isn't.

-Peff
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]