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

Re: [GSoC] Designing a faster index format

From
Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date
Apr 6, 2012, 17:23 UTC
Message-ID
<CACsJy8A2AKApvWJ4JqQn0e=KE1-bx_A9cmCCLxG4A7VkeOrRsg@mail.gmail.com>
In-Reply-To
<CAJo=hJsfXd8J3ndLTMSUFRaH4FG+4YDXdnfFZ13bC+hoA3GE8g@mail.gmail.com>
On Sat, Apr 7, 2012 at 12:13 AM, Shawn Pearce <spearce@spearce.org> wrote:
Show 23 quoted lines
> On Fri, Apr 6, 2012 at 08:44, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
>> On Fri, Apr 6, 2012 at 10:24 PM, Thomas Rast <trast@student.ethz.ch> wrote:
>>> But even so: do we make any promises that (say) git-add is atomic in the
>>> sense that a reader always gets the before-update results or the
>>> after-update results?  Non-builtins (e.g. git add -p) may make small
>>> incremental updates to the index, so they wouldn't be atomic anyway.
>>
>> Take git-checkout. I'm ok with it writing to worktree all old entries,
>> or all new ones, but please not a mix.
>
> Why, what is the big deal? git-checkout has already written the file
> to the local working tree. Its now just reflecting the updated stat
> information in the index. If it does that after each file was touched,
> and it aborts, you still have a partially updated working tree and the
> index will show some updated files as stat clean, but staged relative
> to HEAD. I don't think that is any better or worse than the current
> situation where the working tree is shown as locally dirty but the
> index has no staged files. Either way you have an aborted checkout to
> recover from by retrying, or git reset --hard HEAD.
>
> In the retry case, checkout actually has less to do because the files
> it already cleanly updated match where its going, and thus it doesn't
> have to touch them again.

OK, what about git-commit? If I read your description correctly, you can update entry sha-1 in place too. Running cache-tree on half old half new index definitely creates a broken commit.

A command can also read (which does not require lock), update its internal index, then lock and write. At that time, it may accidentally overwrite whatever another command wrote while it was still preparing the index in memory.

-- 
Duy
Previous: Shawn PearceNext: Shawn Pearce
Message 31 of 36 in “[GSoC] Designing a faster index format”
  1. Thomas GummererMar 20, 2012
  2. Nguyen Thai Ngoc DuyMar 21, 2012
  3. Thomas GummererMar 21, 2012
  4. Nguyen Thai Ngoc DuyMar 21, 2012
  5. Thomas RastMar 21, 2012
  6. Thomas GummererMar 21, 2012
  7. Thomas RastMar 21, 2012
  8. Thomas GummererMar 22, 2012
  9. Thomas RastMar 23, 2012
  10. Thomas GummererMar 25, 2012
  11. Thomas GummererMar 26, 2012
  12. Junio C HamanoMar 26, 2012
  13. Thomas GummererMar 27, 2012
  14. Thomas RastMar 27, 2012
  15. Thomas GummererMar 29, 2012
  16. Junio C HamanoMar 29, 2012
  17. Nguyen Thai Ngoc DuyMar 30, 2012
  18. Thomas GummererApr 2, 2012
  19. Michael HaggertyApr 3, 2012
  20. Nguyen Thai Ngoc DuyApr 3, 2012
  21. Thomas GummererApr 3, 2012
  22. david@lang.hmApr 3, 2012
  23. Thomas GummererApr 4, 2012
  24. Noel GrandinApr 5, 2012
  25. Thomas RastApr 5, 2012
  26. Shawn PearceApr 6, 2012
  27. Nguyen Thai Ngoc DuyApr 6, 2012
  28. Thomas RastApr 6, 2012
  29. Nguyen Thai Ngoc DuyApr 6, 2012
  30. Shawn PearceApr 6, 2012
  31. Nguyen Thai Ngoc DuyApr 6, 2012
  32. Shawn PearceApr 6, 2012
  33. Michael HaggertyApr 5, 2012
  34. Nguyen Thai Ngoc DuyMar 21, 2012
  35. Nguyen Thai Ngoc DuyApr 19, 2012
  36. Jeff KingApr 20, 2012

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.