From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthieu Moy Subject: Re: erratic behavior commit --allow-empty Date: Wed, 03 Oct 2012 10:04:49 +0200 Message-ID: References: <506AA51E.9010209@viscovery.net> <7vzk449449.fsf@alter.siamese.dyndns.org> <7vhaqc7in6.fsf@alter.siamese.dyndns.org> <90464C79DA97415C9D66846A77ECAA4A@PhilipOakley> Mime-Version: 1.0 Content-Type: text/plain Cc: Philip Oakley , Junio C Hamano , Johannes Sixt , git To: Angelo Borsotti X-From: git-owner@vger.kernel.org Wed Oct 03 10:06:03 2012 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TJJxK-0007k6-2R for gcvg-git-2@plane.gmane.org; Wed, 03 Oct 2012 10:05:22 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755790Ab2JCIFE (ORCPT ); Wed, 3 Oct 2012 04:05:04 -0400 Received: from mx1.imag.fr ([129.88.30.5]:33040 "EHLO shiva.imag.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755772Ab2JCIE4 (ORCPT ); Wed, 3 Oct 2012 04:04:56 -0400 Received: from mail-veri.imag.fr (mail-veri.imag.fr [129.88.43.52]) by shiva.imag.fr (8.13.8/8.13.8) with ESMTP id q937xKOG019892 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 3 Oct 2012 09:59:20 +0200 Received: from anie.imag.fr ([129.88.7.32] helo=anie) by mail-veri.imag.fr with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TJJwo-000557-4a; Wed, 03 Oct 2012 10:04:50 +0200 In-Reply-To: (Angelo Borsotti's message of "Wed, 3 Oct 2012 09:45:36 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (shiva.imag.fr [129.88.30.5]); Wed, 03 Oct 2012 09:59:21 +0200 (CEST) X-IMAG-MailScanner-Information: Please contact MI2S MIM for more information X-MailScanner-ID: q937xKOG019892 X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-SpamCheck: X-IMAG-MailScanner-From: matthieu.moy@grenoble-inp.fr MailScanner-NULL-Check: 1349855963.22035@iHZpr40akZtTXT5myB+3BQ Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Angelo Borsotti writes: > I think that you would agree with me that this is not a nice > behaviour. This is fundamentally how Git works. You probably didn't notice it, but if you do echo 'some content' > file1.txt git add file1.txt git commit -m "file1" echo 'some content' > file2.txt git add file2.txt git commit -m "file2" Then the second commit does not "create" a new blob object for file2.txt, because it has the same content as an existing one. But the point is: you really don't care, or indeed, you care about sharing the blob objects to save disk space. > How could a user ever use a command that is not predictable? It is predictible: give it twice the same inputs in the same conditions, and it will yield the same output. You still didn't tell us where the problem was. You are unhappy with having twice the same sha1 for the same object, but what concrete bad consequence does this have? (except for saving bandwidth in addition to disk space when trying to push your commit) -- Matthieu Moy http://www-verimag.imag.fr/~moy/