git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: non-empty index with git commit -a

From
Jeff King <peff@peff.net>
Date
Feb 16, 2011, 22:34 UTC
Message-ID
<20110216223450.GA5617@sigill.intra.peff.net>
In-Reply-To
<7v39nnirfq.fsf@alter.siamese.dyndns.org>
On Wed, Feb 16, 2011 at 01:46:01PM -0800, Junio C Hamano wrote:
Show 10 quoted lines
> > Also it would be not as easy as reflogs - you would have either to save
> > copy of index, or create a tree out of it and save reference in reflog.
> 
> Also note that "Create a tree out of it" is not always a useful way to
> save the state of the index.  The "stash" shares the same issue, but you
> would need an equivalent of a tarball that consists of the index file
> (with conflicted state) and the files in the working tree that corresponds
> to index entries with conflicted states if you want to be useful for
> storing a state away in case you botch the conflict resolution you are
> attempting.

I had assumed it would be a reflog of trees (or more likely parentless commits), just keeping track of useful states. But the usage there isn't very intuitive. You can do "git show index@{5.minutes.ago}:foo.c >bar.c" to recover the state of a file, or even "git read-tree index@{1}" to get a whole state. And those would be enough for the basic "oops, I just want to go back to where I was".

But probably you should be able to do a three-way merge with where you are now, with the HEAD at the time of save as a pseudo-parent. IOW, treat the index state as if you had committed it and put it on a reflog. And in the case that you are at the same HEAD, then a merge collapses into a "fast-forward" to the index state you were at (I put "fast-forward" in quotes because we are obviously not interested in moving HEAD to the pseudo-commit at all, but just what ends up in the index).

I dunno. I haven't thought all that hard about it, so maybe there is a more clever way of doing it. Certainly the porcelain support for "reset to this index, but don't move my HEAD" is not good, nor for "merge this index, but nevermind about recording anything about the commit". They are both conceptually easy to implement in terms of plumbing, but the commands to run them are a little unintuitive.

-Peff
Previous: Junio C HamanoNext: Matthieu Moy
Message 21 of 25 in “non-empty index with git commit -a”
  1. Sverre RabbelierFeb 15, 2011
  2. Jeff KingFeb 16, 2011
  3. Jonathan NiederFeb 16, 2011
  4. Jeff KingFeb 16, 2011
  5. Sverre RabbelierFeb 16, 2011
  6. Nguyen Thai Ngoc DuyFeb 16, 2011
  7. Jonathan NiederFeb 16, 2011
  8. Jeff KingFeb 16, 2011
  9. Sverre RabbelierFeb 16, 2011
  10. Jeff KingFeb 16, 2011
  11. Sverre RabbelierFeb 16, 2011
  12. Jeff KingFeb 16, 2011
  13. Michael J GruberFeb 16, 2011
  14. Jeff KingFeb 16, 2011
  15. Junio C HamanoFeb 16, 2011
  16. Jeff KingFeb 16, 2011
  17. Junio C HamanoFeb 16, 2011
  18. Jeff KingFeb 16, 2011
  19. Jakub NarebskiFeb 16, 2011
  20. Junio C HamanoFeb 16, 2011
  21. Jeff KingFeb 16, 2011
  22. Matthieu MoyFeb 16, 2011
  23. Jeff KingFeb 16, 2011
  24. Junio C HamanoFeb 16, 2011
  25. Matthieu MoyFeb 16, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.