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

Re: [PATCH/RFC v7 0/5] git checkout: optimise away lots of lstat() calls

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 13, 2009, 20:17 UTC
Message-ID
<7viqoj6jv7.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<1231849748-8244-1-git-send-email-barvik@broadpark.no>
Kjetil Barvik <barvik@broadpark.no> writes:
Show 6 quoted lines
> Junio, I hope it is possible to use patches 1/5, 2/5 and 3/5 from this
> version instead of 1/3, 2/3 and 3/3 from version 6, for the possible
> future in origin/pu?  See also a) above.  Thanks in advance!
>
> In general, are we allowed to redesign the patch-series while the
> patches is inside origin/pu?

You won't be too far off if you thought of 'pu' branch nothing more than my bookmarks into the list archive. They are interesting enough to keep an eye on their evolution but not yet stable enough to go into initial round of wider testing and incremental development which starts to happen when they hit 'next'.

So yes, while you are not yet confident that the series does not need major redesign, please keep sending replacements (not incremental updates), making it clear that you still have reservations and I'll keep them in 'pu', until the initial barrage of "Oh, I think this way is better", "The previous review comments were valuable, and this round contains all of them" is over and things seem to stabilize into a testable shape.

Personally I felt your v5 and later ones were already 'next' material, and the only reason why the series haven't landed on 'next' was because you kept sending updates before I sat down in the evening and said "Ok, this looks good---let's merge it to 'next'". Instead I ended up saying "Hmph, I thought it looked good already but the author seems not satisfied yet; there is another round of update to replace the previous one. Let's queue it in 'pu', as it may be updated again, and I have to also look at series from other people.' ;-)

Previous: Kjetil Barvik
Message 7 of 7 in “git checkout: optimise away lots of lstat() calls”
  1. 0/5 git checkout: optimise away lots of lstat() callsKjetil Barvik, Jan 13, 2009
  2. 1/5 lstat_cache(): more cache effective symlink/directory detectionKjetil Barvik, Jan 13, 2009
  3. 2/5 lstat_cache(): introduce has_symlink_or_noent_leading_path() functionKjetil Barvik, Jan 13, 2009
  4. 3/5 lstat_cache(): introduce has_dirs_only_path() functionKjetil Barvik, Jan 13, 2009
  5. 4/5 lstat_cache(): introduce invalidate_lstat_cache() functionKjetil Barvik, Jan 13, 2009
  6. 5/5 lstat_cache(): introduce clear_lstat_cache() functionKjetil Barvik, Jan 13, 2009
  7. Junio C HamanoJan 13, 2009

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.