From: Junio C Hamano <gitster@pobox.com>
To: Kjetil Barvik <barvik@broadpark.no>
Cc: git@vger.kernel.org, Pete Harlan <pgit@pcharlan.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH/RFC v7 0/5] git checkout: optimise away lots of lstat() calls
Date: Tue, 13 Jan 2009 12:17:48 -0800 [thread overview]
Message-ID: <7viqoj6jv7.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <1231849748-8244-1-git-send-email-barvik@broadpark.no> (Kjetil Barvik's message of "Tue, 13 Jan 2009 13:29:03 +0100")
Kjetil Barvik <barvik@broadpark.no> writes:
> 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.' ;-)
prev parent reply other threads:[~2009-01-13 20:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-13 12:29 [PATCH/RFC v7 0/5] git checkout: optimise away lots of lstat() calls Kjetil Barvik
2009-01-13 12:29 ` [PATCH/RFC v7 1/5] lstat_cache(): more cache effective symlink/directory detection Kjetil Barvik
2009-01-13 12:29 ` [PATCH/RFC v7 2/5] lstat_cache(): introduce has_symlink_or_noent_leading_path() function Kjetil Barvik
2009-01-13 12:29 ` [PATCH/RFC v7 3/5] lstat_cache(): introduce has_dirs_only_path() function Kjetil Barvik
2009-01-13 12:29 ` [PATCH/RFC v7 4/5] lstat_cache(): introduce invalidate_lstat_cache() function Kjetil Barvik
2009-01-13 12:29 ` [PATCH/RFC v7 5/5] lstat_cache(): introduce clear_lstat_cache() function Kjetil Barvik
2009-01-13 20:17 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7viqoj6jv7.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=barvik@broadpark.no \
--cc=git@vger.kernel.org \
--cc=pgit@pcharlan.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).