From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Nguyen Thai Ngoc Duy" Subject: Re: What's cooking in git.git (Nov 2008, #06; Wed, 26) Date: Sun, 30 Nov 2008 17:29:08 +0700 Message-ID: References: <7v7i6qc8r0.fsf@gitster.siamese.dyndns.org> <7vtz9s8uzu.fsf@gitster.siamese.dyndns.org> <20081128192033.GF23984@spearce.org> <7voczz4cfb.fsf@gitster.siamese.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Junio C Hamano" , "Shawn O. Pearce" , "Johannes Schindelin" , git@vger.kernel.org To: "Daniel Barkalow" X-From: git-owner@vger.kernel.org Sun Nov 30 11:30:35 2008 Return-path: Envelope-to: gcvg-git-2@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1L6jZT-000808-2N for gcvg-git-2@gmane.org; Sun, 30 Nov 2008 11:30:35 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751164AbYK3K3L (ORCPT ); Sun, 30 Nov 2008 05:29:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751163AbYK3K3L (ORCPT ); Sun, 30 Nov 2008 05:29:11 -0500 Received: from fg-out-1718.google.com ([72.14.220.158]:64423 "EHLO fg-out-1718.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751162AbYK3K3K (ORCPT ); Sun, 30 Nov 2008 05:29:10 -0500 Received: by fg-out-1718.google.com with SMTP id 19so1469083fgg.17 for ; Sun, 30 Nov 2008 02:29:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=GK0MvOTn7QCYTedJnvIO3eg0AjcxV1JQheETF7PW4kM=; b=ubv+fPIfeedRD7aUsRS1WrM2hedPILZTgrtl1G57fh5PwvO0OBCflTSputl8GE0GEB E3qDW0nAsw5VK+IDwBSB9fUO+rWofRmbIGyL3fY/Uqcf47pEHQRm5moPbxHiEwmPzAo8 y7P5iRGmapqYovAgYN2P0LYa5tYykCiW+F8MI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=I7aXD3ky5BPoEVKit9VAl57ZCzkzDnFkxO1hodERC2VnLebuYV5g8dNKOwcUIZscm8 GIcJiLnRkdttKXKx+ZbOMAMgbeopWNbqvjBgfEo2NrmFvZ+XZ08Od5WKuoZlYu659era /waU6fTJXmTUsME7ExWHq2SYsM7YU6YX3URgs= Received: by 10.86.63.19 with SMTP id l19mr5895587fga.15.1228040948524; Sun, 30 Nov 2008 02:29:08 -0800 (PST) Received: by 10.86.62.13 with HTTP; Sun, 30 Nov 2008 02:29:08 -0800 (PST) In-Reply-To: Content-Disposition: inline Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On 11/29/08, Nguyen Thai Ngoc Duy wrote: > On 11/29/08, Daniel Barkalow wrote: > > If there's any need for this to be distinguished from "assume unchanged", > > I think it should be used with, not instead of, the CE_VALID bit; and it > > could probably use some bit in the stat info section, since we don't need > > stat info if we know by assumption that the entry is valid. > > > Interesting. I'll think more about this. > As I said, CE_VALID implies all files are present. I could make CE_NO_CHECKOUT to be used with CE_VALID, but I would need to check all CE_VALID code path to make sure the behaviour remains if CE_NO_CHECKOUT is absent. It's just more intrusive. I have nothing against storing CE_NO_CHECKOUT in stat info except that it seems inappropriate/hidden place to do. ce_flags is more obvious choice. I haven't looked closely to stat info code in read-cache.c though. -- Duy