From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Raymond Subject: How can I tell if a file is ignored by git? Date: Fri, 9 Apr 2010 00:04:34 -0400 (EDT) Message-ID: <20100409040434.8602620CBBC@snark.thyrsus.com> To: git@vger.kernel.org X-From: git-owner@vger.kernel.org Fri Apr 09 06:04:43 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O05SU-0001Yj-Qv for gcvg-git-2@lo.gmane.org; Fri, 09 Apr 2010 06:04:43 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750889Ab0DIEEg (ORCPT ); Fri, 9 Apr 2010 00:04:36 -0400 Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:52608 "EHLO snark.thyrsus.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1749667Ab0DIEEf (ORCPT ); Fri, 9 Apr 2010 00:04:35 -0400 Received: by snark.thyrsus.com (Postfix, from userid 23) id 8602620CBBC; Fri, 9 Apr 2010 00:04:34 -0400 (EDT) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: I'm planning some work on Emacs VC mode. I need a command I can run on a path to tell if it's ignored by git. -- Eric S. Raymond If gun laws in fact worked, the sponsors of this type of legislation should have no difficulty drawing upon long lists of examples of criminal acts reduced by such legislation. That they cannot do so after a century and a half of trying -- that they must sweep under the rug the southern attempts at gun control in the 1870-1910 period, the northeastern attempts in the 1920-1939 period, the attempts at both Federal and State levels in 1965-1976 -- establishes the repeated, complete and inevitable failure of gun laws to control serious crime. -- Senator Orrin Hatch, in a 1982 Senate Report From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jacob Helwig Subject: Re: How can I tell if a file is ignored by git? Date: Thu, 8 Apr 2010 21:10:49 -0700 Message-ID: References: <20100409040434.8602620CBBC@snark.thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: git@vger.kernel.org To: Eric Raymond X-From: git-owner@vger.kernel.org Fri Apr 09 06:11:19 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O05Ys-000376-0N for gcvg-git-2@lo.gmane.org; Fri, 09 Apr 2010 06:11:18 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751402Ab0DIELN (ORCPT ); Fri, 9 Apr 2010 00:11:13 -0400 Received: from qw-out-2122.google.com ([74.125.92.25]:43744 "EHLO qw-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750918Ab0DIELM (ORCPT ); Fri, 9 Apr 2010 00:11:12 -0400 Received: by qw-out-2122.google.com with SMTP id 8so1068766qwh.37 for ; Thu, 08 Apr 2010 21:11:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:received:message-id:subject:to:cc:content-type; bh=ekZvpIdKmZgK3EhkD/DzTUrcx6vt1f4aQyfOfSKI0lk=; b=A5RV4xV1Z0EjbFuI9qstsW9OPXqKzc/8VactGcvrDhvbcpS/Y2tousypXfRxZx89O+ fvG4Ac+TLMeT1XYQHbd1AF1XINixDZb8M63+j1Uar2NGigNBp5ZRdYN74GaQqtFQTDCt I3/CgXpeYFCOhiPC2k6oza8VlnoAvjBo5dfoY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=bkU5YK8EKl/24gM5+W7SEZjuHTkPlLUocA+HlaWk2EipKO3uJ+xjMDidgZ2dXvpVrs xgjX1NwFjozaDkrB1fDvW1iB2Mt95JrVj6HPSErHlaGf+X4w7FBJ35Eaaav2oHXS1Nvw x4kI/tlD9tQKv0v/ZUFPXvzeT3WqsyP81OF/Y= Received: by 10.229.215.2 with HTTP; Thu, 8 Apr 2010 21:10:49 -0700 (PDT) In-Reply-To: <20100409040434.8602620CBBC@snark.thyrsus.com> Received: by 10.229.251.72 with SMTP id mr8mr1857139qcb.30.1270786271445; Thu, 08 Apr 2010 21:11:11 -0700 (PDT) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Thu, Apr 8, 2010 at 21:04, Eric Raymond wrote: > I'm planning some work on Emacs VC mode. > > I need a command I can run on a path to tell if it's ignored by git. What about a variant of: git ls-files -i -o --exclude-standard From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ramkumar Ramachandra Subject: Re: How can I tell if a file is ignored by git? Date: Fri, 9 Apr 2010 10:20:13 +0530 Message-ID: References: <20100409040434.8602620CBBC@snark.thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: git@vger.kernel.org, Jacob Helwig To: Eric Raymond X-From: git-owner@vger.kernel.org Fri Apr 09 06:50:53 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O06BA-0004FW-Jr for gcvg-git-2@lo.gmane.org; Fri, 09 Apr 2010 06:50:52 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753111Ab0DIEuk (ORCPT ); Fri, 9 Apr 2010 00:50:40 -0400 Received: from mail-gy0-f174.google.com ([209.85.160.174]:51161 "EHLO mail-gy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753067Ab0DIEue (ORCPT ); Fri, 9 Apr 2010 00:50:34 -0400 Received: by gyg13 with SMTP id 13so1592722gyg.19 for ; Thu, 08 Apr 2010 21:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :from:date:received:message-id:subject:to:cc:content-type; bh=fCTMamX9DzJ+E7Q1e2Tk9TSvKKrASHrv78p0/utDVW4=; b=Qq1YDbi14d9sBogRPEpMzc/cI/7hY7ht/i/debBynnhH20UTnWlM4qm70FvPPe2+A8 1gGdZ0OnfEVrgsc7FJY3TCDhDVmC746tb5OLsPwSKt1FzybHfcF40DfHAu8pxRQSrHnS gxLmFMDJpIEDoyjYgE9TNqAw5aQV5Q5wBNU7Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=XbS7nRW05osaqv10VsUSs33SjleNAj79W+ywIaEpt7lIB8e9HybH7VDOb7QuZdKFPn oLvub+lv/PoPgRj5HpoHDc+BK1mq3qn7cdY00vOyi1xUqR8IsoNlWDd5/zzhYaWmSo45 bbqAoCfzFndzY0zOVU0Smyd4LaxX9sceHVK9Y= Received: by 10.90.69.14 with HTTP; Thu, 8 Apr 2010 21:50:13 -0700 (PDT) In-Reply-To: <20100409040434.8602620CBBC@snark.thyrsus.com> Received: by 10.90.17.23 with SMTP id 23mr443003agq.82.1270788633176; Thu, 08 Apr 2010 21:50:33 -0700 (PDT) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Hi, > I'm planning some work on Emacs VC mode. I personally use Magit [1]. Just thought you might want to look at it. -- Ram [1] http://zagadka.vm.bytemark.co.uk/magit/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?w4Z2YXIgQXJuZmrDtnLDsCBCamFybWFzb24=?= Subject: Re: How can I tell if a file is ignored by git? Date: Fri, 9 Apr 2010 05:01:46 +0000 Message-ID: References: <20100409040434.8602620CBBC@snark.thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Eric Raymond , git@vger.kernel.org, Jacob Helwig To: Ramkumar Ramachandra X-From: git-owner@vger.kernel.org Fri Apr 09 07:01:58 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O06Lt-00017Z-F3 for gcvg-git-2@lo.gmane.org; Fri, 09 Apr 2010 07:01:57 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752801Ab0DIFBu (ORCPT ); Fri, 9 Apr 2010 01:01:50 -0400 Received: from mail-bw0-f209.google.com ([209.85.218.209]:47169 "EHLO mail-bw0-f209.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750845Ab0DIFBt (ORCPT ); Fri, 9 Apr 2010 01:01:49 -0400 Received: by bwz1 with SMTP id 1so2257273bwz.21 for ; Thu, 08 Apr 2010 22:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=BtSRQow2KnpITNsEsxRvw5+6FlFjIUCc/iuhCRFAyh8=; b=UtnBj2X4EtRXK2YQI2e0oQbE4ORDjbL6j8BxZAhkTiObSSQHKaDs6TOpwlTz0GBrBR AIUIM77pWLZqgPJOZVVsTm0uZ2YnWy7RppQDlhMHkBdMXBNLQQ/Z+wEnqHI2LHPy1yHo OXwwpGvQZ5DgEGLPWC/Fe9RqMJTNxekNq+hQ4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=L9r2fhGfDSPWWOcsLSQ8kJezFXZCdpAnZtznfKSI4n6Yje1BcySbTpMfc3LngjZAu6 eG3sSk4lvaRX0ATj1pj6gdUwjpJRRNHwkTnUGazLgG7vlC0eDxdF3zPJ5ZzQAQqg2HhF mYmDtSHlQJgmljNST9K1TB0ugq+sew7eGd1nU= Received: by 10.204.121.195 with HTTP; Thu, 8 Apr 2010 22:01:46 -0700 (PDT) In-Reply-To: Received: by 10.204.132.214 with SMTP id c22mr1255361bkt.60.1270789306875; Thu, 08 Apr 2010 22:01:46 -0700 (PDT) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Fri, Apr 9, 2010 at 04:50, Ramkumar Ramachandra wrote: > I personally use Magit [1]. Just thought you might want to look at it. Eric might be a bit too personally invested vc.el at this point :) But yeah, magit is great, unlike vc-dir and vc it makes really good use of Git's index & stash features. Instead of staging individual files for commit you stage chunks, the quality and granularity of my commits has gone up since I switched to it from vc due to that. But to help with the original question: magit has an ignore feature but it doesn't check whether something is ignored, it just counts on you not ignoring already ignored stuff because it isn't displayed to you. Depending on how you're planning to implement .gitignore support you might want to go this route. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Raymond Subject: Re: How can I tell if a file is ignored by git? Date: Fri, 9 Apr 2010 06:50:15 -0400 Organization: Eric Conspiracy Secret Labs Message-ID: <20100409105015.GA27353@thyrsus.com> References: <20100409040434.8602620CBBC@snark.thyrsus.com> Reply-To: esr@thyrsus.com Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Ramkumar Ramachandra , Eric Raymond , git@vger.kernel.org, Jacob Helwig To: =?iso-8859-1?Q?=C6var_Arnfj=F6r=F0?= Bjarmason X-From: git-owner@vger.kernel.org Fri Apr 09 12:50:59 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O0Bne-00032y-RG for gcvg-git-2@lo.gmane.org; Fri, 09 Apr 2010 12:50:59 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755617Ab0DIKuT convert rfc822-to-quoted-printable (ORCPT ); Fri, 9 Apr 2010 06:50:19 -0400 Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:46688 "EHLO snark.thyrsus.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755565Ab0DIKuQ (ORCPT ); Fri, 9 Apr 2010 06:50:16 -0400 Received: by snark.thyrsus.com (Postfix, from userid 23) id DD6BB20CBBC; Fri, 9 Apr 2010 06:50:15 -0400 (EDT) Content-Disposition: inline In-Reply-To: X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.20 (2009-06-14) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: =C6var Arnfj=F6r=F0 Bjarmason : > On Fri, Apr 9, 2010 at 04:50, Ramkumar Ramachandra wrote: > > I personally use Magit [1]. Just thought you might want to look at = it. >=20 > Eric might be a bit too personally invested vc.el at this point :) Well, there's that, and then there's the fact that I really do use multiple VCSes. Consistent interface for all of them -> win.=20 --=20 Eric S. Raymond From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Raymond Subject: Status of all files (was: Re: How can I tell if a file is ignored by git? Date: Fri, 9 Apr 2010 07:32:48 -0400 Organization: Eric Conspiracy Secret Labs Message-ID: <20100409113248.GB27353@thyrsus.com> References: <20100409040434.8602620CBBC@snark.thyrsus.com> Reply-To: esr@thyrsus.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Eric Raymond , git@vger.kernel.org To: Jacob Helwig X-From: git-owner@vger.kernel.org Fri Apr 09 13:32:55 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O0CSE-0003Qc-UH for gcvg-git-2@lo.gmane.org; Fri, 09 Apr 2010 13:32:55 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751726Ab0DILct (ORCPT ); Fri, 9 Apr 2010 07:32:49 -0400 Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:33069 "EHLO snark.thyrsus.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750943Ab0DILcs (ORCPT ); Fri, 9 Apr 2010 07:32:48 -0400 Received: by snark.thyrsus.com (Postfix, from userid 23) id 1AC6120CBBC; Fri, 9 Apr 2010 07:32:48 -0400 (EDT) Content-Disposition: inline In-Reply-To: X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.20 (2009-06-14) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Jacob Helwig : > On Thu, Apr 8, 2010 at 21:04, Eric Raymond wrote: > > I'm planning some work on Emacs VC mode. > > > > I need a command I can run on a path to tell if it's ignored by git. > > What about a variant of: > git ls-files -i -o --exclude-standard That will do nicely, thank you. There could be something better. Emacs VC mode, and other similar front ends, would be greatly aided by a command that lists all files, each with a status code it can understand. Our canonical list (omitting two that apply only to locking systems) is: 'up-to-date The working file is unmodified with respect to the latest version on the current branch, and not locked. 'edited The working file has been edited by the user. 'needs-update The file has not been edited by the user, but there is a more recent version on the current branch stored in the master file. 'needs-merge The file has been edited by the user, and there is also a more recent version on the current branch stored in the master file. This state can only occur if locking is not used for the file. 'added Scheduled to go into the repository on the next commit. 'removed Scheduled to be deleted from the repository on next commit. 'conflict The file contains conflicts as the result of a merge. 'missing The file is not present in the file system, but the VC system still tracks it. 'ignored The file showed up in a dir-status listing with a flag indicating the version-control system is ignoring it, 'unregistered The file is not under version control. The -t mode of ls-files appears to be almost what is wanted, but not quite. (Among other things, it does not list ignored files.) I request comment on some related questions: 1. How do these statuses map to git terminology? My tentative map, in terms of git file-list -t codes, is up-to-date = H? edited = C needs-update = no equivalent needs-merge = no equivalent added = no equivalent removed = K conflict = no equivalent missing = R ignored = no equivalent unregistered = no equivalent I am unclear on what your "unmerged" (M) status means. 2. I've played with various option combinations, but I can't seem to find one that lists these codes for all files. Is there one? 3. Is the use case for -t such that it would make sense to modify it so it does a complete listing? 4. If the answer to question 3 is 'yes', is there some Emacs user here who already knows git internals and would be willing to do this in order to help VC be faster and more effective? I would handle the VC end, of course. -- Eric S. Raymond From mboxrd@z Thu Jan 1 00:00:00 1970 From: merlyn@stonehenge.com (Randal L. Schwartz) Subject: Re: Status of all files (was: Re: How can I tell if a file is ignored by git? Date: Fri, 09 Apr 2010 05:11:12 -0700 Message-ID: <864ojkx1un.fsf@red.stonehenge.com> References: <20100409040434.8602620CBBC@snark.thyrsus.com> <20100409113248.GB27353@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jacob Helwig , Eric Raymond , git@vger.kernel.org To: esr@thyrsus.com X-From: git-owner@vger.kernel.org Fri Apr 09 14:18:34 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O0DAO-00064C-8l for gcvg-git-2@lo.gmane.org; Fri, 09 Apr 2010 14:18:33 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751244Ab0DIMS1 (ORCPT ); Fri, 9 Apr 2010 08:18:27 -0400 Received: from red.stonehenge.com ([208.79.95.2]:57004 "EHLO red.stonehenge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751041Ab0DIMS0 (ORCPT ); Fri, 9 Apr 2010 08:18:26 -0400 X-Greylist: delayed 433 seconds by postgrey-1.27 at vger.kernel.org; Fri, 09 Apr 2010 08:18:26 EDT Received: by red.stonehenge.com (Postfix, from userid 1001) id AF8D487D4; Fri, 9 Apr 2010 05:11:12 -0700 (PDT) x-mayan-date: Long count = 12.19.17.4.13; tzolkin = 5 Ben; haab = 6 Pop In-Reply-To: <20100409113248.GB27353@thyrsus.com> (Eric Raymond's message of "Fri, 9 Apr 2010 07:32:48 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: >>>>> "Eric" == Eric Raymond writes: Eric> There could be something better. Emacs VC mode, and other similar Eric> front ends, would be greatly aided by a command that lists all files, Eric> each with a status code it can understand. Our canonical list Eric> (omitting two that apply only to locking systems) is: A lot of these don't make sense for git and other DVCS. How have hg and bzr interpreted these "canonical" states? For example: Eric> 'needs-update The file has not been edited by the user, but there is Eric> a more recent version on the current branch stored Eric> in the master file. This makes sense only with a file-based VCS, not a tree-based VCS like git. Eric> 'needs-merge The file has been edited by the user, and there is also Eric> a more recent version on the current branch stored in Eric> the master file. This state can only occur if locking Eric> is not used for the file. Ditto. Eric> 'removed Scheduled to be deleted from the repository Eric> on next commit. Not useful in git. Eric> 'missing The file is not present in the file system, but the VC Eric> system still tracks it. Not available in git. (If it's not a real file, it can't be tracked. :) Eric> 'ignored The file showed up in a dir-status listing with a flag Eric> indicating the version-control system is ignoring it, Eric> 'unregistered The file is not under version control. These two would be identical in git. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Narebski Subject: Re: Status of all files (was: Re: How can I tell if a file is ignored by git? Date: Fri, 09 Apr 2010 05:56:09 -0700 (PDT) Message-ID: References: <20100409040434.8602620CBBC@snark.thyrsus.com> <20100409113248.GB27353@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jacob Helwig , Eric Raymond , git@vger.kernel.org To: esr@thyrsus.com X-From: git-owner@vger.kernel.org Fri Apr 09 14:56:22 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O0Dkw-0007yo-H8 for gcvg-git-2@lo.gmane.org; Fri, 09 Apr 2010 14:56:19 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751593Ab0DIM4N (ORCPT ); Fri, 9 Apr 2010 08:56:13 -0400 Received: from mail-fx0-f223.google.com ([209.85.220.223]:61886 "EHLO mail-fx0-f223.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751077Ab0DIM4M (ORCPT ); Fri, 9 Apr 2010 08:56:12 -0400 Received: by fxm23 with SMTP id 23so2810338fxm.21 for ; Fri, 09 Apr 2010 05:56:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:received :x-authentication-warning:to:cc:subject:references:from:date :in-reply-to:message-id:lines:user-agent:mime-version:content-type; bh=kZvTw+jaHeV4BQBnPEUW7G81CNE+N878M7LwIn9yrhE=; b=IhoCj8jhs7zNGH9uTO8A6qe9SkWe+UQ0bNttBw4JwZKjDCARvm7T3WoTyyo2PRpOkq Y/Yg9vwrvgfkr/Tf3tzLJNvNHKoxTq35/BBSarR4sqD8uT21BNv3OPu0/Xhr3RrIk31w tQFgIpLRcKY5qgb5bk0za29oebubfFSEPJLVY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=x-authentication-warning:to:cc:subject:references:from:date :in-reply-to:message-id:lines:user-agent:mime-version:content-type; b=MfGh933+ywHZl/fV9k35Fir49hUAItwbCaUCyKp7tC9xjTOCjefbFe2JxbygseGKzr NmJVnlD7dKAKufciTWnmqvqT9AhHsMWVUM1CjfmIXIEEph8CjSBs2/Rz1pUSOwgH1BoG TkR4/LVEUdh0xs3ryPqyRRJCCQNqRo0tfDV8U= Received: by 10.102.17.29 with SMTP id 29mr20710muq.45.1270817769991; Fri, 09 Apr 2010 05:56:09 -0700 (PDT) Received: from localhost.localdomain (abvc167.neoplus.adsl.tpnet.pl [83.8.200.167]) by mx.google.com with ESMTPS id n10sm5158341mue.12.2010.04.09.05.56.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Apr 2010 05:56:08 -0700 (PDT) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (8.13.4/8.13.4) with ESMTP id o39CtaA3011919; Fri, 9 Apr 2010 14:55:41 +0200 Received: (from jnareb@localhost) by localhost.localdomain (8.13.4/8.13.4/Submit) id o39CtC4d011911; Fri, 9 Apr 2010 14:55:12 +0200 X-Authentication-Warning: localhost.localdomain: jnareb set sender to jnareb@gmail.com using -f In-Reply-To: <20100409113248.GB27353@thyrsus.com> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Eric Raymond writes: > Jacob Helwig : > > On Thu, Apr 8, 2010 at 21:04, Eric Raymond wrote: > > > I'm planning some work on Emacs VC mode. > > > > > > I need a command I can run on a path to tell if it's ignored by git. > > > > What about a variant of: > > git ls-files -i -o --exclude-standard > > That will do nicely, thank you. > > There could be something better. Emacs VC mode, and other similar > front ends, would be greatly aided by a command that lists all files, > each with a status code it can understand. There is also git status --short > Our canonical list (omitting two that apply only to locking systems) > is: > > 'up-to-date The working file is unmodified with respect to the > latest version on the current branch, and not locked. In Git you don't have locking, but you have three versions: in the working area (the working file), in the index, and latest version on the current branch (the HEAD version). So 'up-to-date in Git would probably mean working tree = cached = HEAD version. > > 'edited The working file has been edited by the user. Does this include stat-dirty files, i.e. if file has been modified (mtime), but the contents is the same in working file and in HEAD version? See also 'git update-index --refresh' etc. > > 'needs-update The file has not been edited by the user, but there is > a more recent version on the current branch stored > in the master file. Needs *update* looks like it came from centralized VCS like CVS and Subversion, where you use update-the-commit method. You can't say that HEAD version is more recent that working file... The rought equivalent would be that upstream branch for current branch (e.g. 'origin/master' can be upstream for 'master' branch) is in fast-forward state i.e. current branch is direct ancestor of corresponding upstream branch, and the file was modified upstream. > > 'needs-merge The file has been edited by the user, and there is also > a more recent version on the current branch stored in > the master file. This state can only occur if locking > is not used for the file. This, like 'needs-update, looks like it is relevant only in update-the-commit workflow centralized VCS. > > 'added Scheduled to go into the repository on the next commit. > > 'removed Scheduled to be deleted from the repository on next commit. > > 'conflict The file contains conflicts as the result of a merge. Note that with Git you can have other merge conflict than simple CONFLICT(contents). With CONFLICT(rename/rename) for example the file would not contain textual conflict, so e.g. it won't have conflict markers, etc. > > 'missing The file is not present in the file system, but the VC > system still tracks it. Note that file might be missing only in working directory, and can be missing both in working directory and the index (staging area). > > 'ignored The file showed up in a dir-status listing with a flag > indicating the version-control system is ignoring it, > > 'unregistered The file is not under version control. [...] > I am unclear on what your "unmerged" (M) status means. Probably 'conflict. -- Jakub Narebski Poland ShadeHawk on #git From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Raymond Subject: Re: Status of all files (was: Re: How can I tell if a file is ignored by git? Date: Fri, 9 Apr 2010 09:20:37 -0400 Organization: Eric Conspiracy Secret Labs Message-ID: <20100409132037.GA27899@thyrsus.com> References: <20100409040434.8602620CBBC@snark.thyrsus.com> <20100409113248.GB27353@thyrsus.com> <864ojkx1un.fsf@red.stonehenge.com> Reply-To: esr@thyrsus.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jacob Helwig , Eric Raymond , git@vger.kernel.org To: "Randal L. Schwartz" X-From: git-owner@vger.kernel.org Fri Apr 09 15:20:44 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O0E8a-00038d-3F for gcvg-git-2@lo.gmane.org; Fri, 09 Apr 2010 15:20:44 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752188Ab0DINUj (ORCPT ); Fri, 9 Apr 2010 09:20:39 -0400 Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:52162 "EHLO snark.thyrsus.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751743Ab0DINUi (ORCPT ); Fri, 9 Apr 2010 09:20:38 -0400 Received: by snark.thyrsus.com (Postfix, from userid 23) id 5EF44475FEF; Fri, 9 Apr 2010 09:20:37 -0400 (EDT) Content-Disposition: inline In-Reply-To: <864ojkx1un.fsf@red.stonehenge.com> X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.20 (2009-06-14) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Randal L. Schwartz : > A lot of these don't make sense for git and other DVCS. How have > hg and bzr interpreted these "canonical" states? That asks the question the wrong way around. These state codes are used to change how VC *itself* performs when you fire various commands; the VCSes called by the VC back ends never have to 'interpret' them. It is not expected that every VCS will report all of them; in particular, as you say, some only make sense in locking systems. When VC knows it's dealing with a merging system, it will never go down a logic path where a locking-related state is checked for. I deleted two of the locking-system-only states from what you saw, but may have missed others; I don't completely understand all the states, because at least eleven other people hacked on VC during the 15 years I was doing other things and added several that were not in my original design. (There is some excuse for this. Emacs VC is probably unique in that its ontology has to be rich enough to accomodate *every VCS there is*. Nothing else even attempts that, AFAIK.) But to answer your question at least in part, here is a piece of code mapping status codes from Mercurial's hg status -A command to Emacs state codes. (when (eq 0 status) (when (null (string-match ".*: No such file or directory$" out)) (let ((state (aref out 0))) (cond ((eq state ?=) 'up-to-date) ((eq state ?A) 'added) ((eq state ?M) 'edited) ((eq state ?I) 'ignored) ((eq state ?R) 'removed) ((eq state ?!) 'missing) ((eq state ??) 'unregistered) ((eq state ?C) 'up-to-date) ;; Older mercurials use this (t 'up-to-date))))))) This is failing to report at least one interesting state, which is 'conflict. But otherwise it looks pretty complete. What I'm really looking for is a git functional equivalent of hg status -A. The git backend presently uses diff-index and interprets the output in a way that I fear is rather brittle. I'm inclined to think you are right that 'need-update and 'need-merge don't make any sense in a tree-oriented VCS. On the other hand, SVN and Monotone both report them. On the gripping hand, I'm not certain these qualify as "tree-oriented" in quite as strong a sense as hg and git do. I need to understand this better. If nothing else, perhaps this discussion will lead to me being able to document Emacs statuses more completely. There is a fair amount of murk around them now, because the mode did a lot of growing by accretion that I have not completely cleaned up yet. > Eric> 'removed Scheduled to be deleted from the repository > Eric> on next commit. > > Not useful in git. I disagree. At least, git status reports "removed" files before a commit. This seems like the logical state for a file after it has been subjected to "git rm' but before commit. > Eric> 'missing The file is not present in the file system, but the VC > Eric> system still tracks it. > > Not available in git. (If it's not a real file, it can't be tracked. :) What about a file that has been deleted from the working copy with ordinary rm (as opposed to git rm) so it's still in the index? Wouldn't that qualify? > Eric> 'ignored The file showed up in a dir-status listing with a flag > Eric> indicating the version-control system is ignoring it, > > Eric> 'unregistered The file is not under version control. > > These two would be identical in git. Certainly not. If I have "*.o" in my .gitignore, and two untracked files foo.c and foo.o in my directory, both are unregistered, but only foo.o is ignored. Emacs wants to see foo.c -> 'unregistered but foo.o -> 'ignored. -- Eric S. Raymond From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Raymond Subject: Re: Status of all files (was: Re: How can I tell if a file is ignored by git? Date: Fri, 9 Apr 2010 10:02:15 -0400 Organization: Eric Conspiracy Secret Labs Message-ID: <20100409140215.GB27899@thyrsus.com> References: <20100409040434.8602620CBBC@snark.thyrsus.com> <20100409113248.GB27353@thyrsus.com> Reply-To: esr@thyrsus.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jacob Helwig , Eric Raymond , git@vger.kernel.org To: Jakub Narebski X-From: git-owner@vger.kernel.org Fri Apr 09 16:02:58 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O0EnP-0006mO-D3 for gcvg-git-2@lo.gmane.org; Fri, 09 Apr 2010 16:02:55 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753064Ab0DIOCS (ORCPT ); Fri, 9 Apr 2010 10:02:18 -0400 Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:52109 "EHLO snark.thyrsus.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752618Ab0DIOCQ (ORCPT ); Fri, 9 Apr 2010 10:02:16 -0400 Received: by snark.thyrsus.com (Postfix, from userid 23) id 5095A475FEF; Fri, 9 Apr 2010 10:02:15 -0400 (EDT) Content-Disposition: inline In-Reply-To: X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.20 (2009-06-14) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Jakub Narebski : > There is also > > git status --short Not documented in my installed version, 1.6.3.3. Where can I go in the repo to read about this? > > Our canonical list (omitting two that apply only to locking systems) > > is: > > > > 'up-to-date The working file is unmodified with respect to the > > latest version on the current branch, and not locked. > > In Git you don't have locking, but you have three versions: in the > working area (the working file), in the index, and latest version on > the current branch (the HEAD version). > > So 'up-to-date in Git would probably mean working tree = cached = HEAD > version. Yes, that was what I thought. Is this what ls-files is reporting as 'H'? (The ls-files -t codes need better documentation. If I get detailed enough answers, I will write some.) > > > > 'edited The working file has been edited by the user. > > Does this include stat-dirty files, i.e. if file has been modified > (mtime), but the contents is the same in working file and in HEAD > version? No, it does not. Thank you for asking that question, I have just added a note about this to the VC code exactly where it will do the most good. > > > > 'needs-update The file has not been edited by the user, but there is > > a more recent version on the current branch stored > > in the master file. > > Needs *update* looks like it came from centralized VCS like CVS and > Subversion, where you use update-the-commit method. You can't say > that HEAD version is more recent that working file... > > The rought equivalent would be that upstream branch for current > branch (e.g. 'origin/master' can be upstream for 'master' branch) is > in fast-forward state i.e. current branch is direct ancestor of > corresponding upstream branch, and the file was modified upstream. Agreed. But there's no way to tell that this is the case without doing a pull operation or otherwise querying origin, and I'm not going to do that. Explanation: My general rule for DVCS back ends is that the status commands aren't allowed to do network operations, and it's OK for them not to report a state code if that would be required. This is so VC will fully support disconnected operation when the VCS does. I have, however, added a note to vc-git.el explaining that this is possible if we ever teach the mode front end to behave differently when it knows it has live Internet. I might do this in the future. > > > > 'needs-merge The file has been edited by the user, and there is also > > a more recent version on the current branch stored in > > the master file. This state can only occur if locking > > is not used for the file. > > This, like 'needs-update, looks like it is relevant only in > update-the-commit workflow centralized VCS. Following your previous logic, I think it would make sense to set this if we could detect that the upstream of the current branch has forward commits touching this file. Again, this would require a network operation in the general case. > > 'conflict The file contains conflicts as the result of a merge. > > Note that with Git you can have other merge conflict than simple > CONFLICT(contents). With CONFLICT(rename/rename) for example the file > would not contain textual conflict, so e.g. it won't have conflict > markers, etc. It is unclear what Emacs wants in this situation; I will try to find out. The documentation says this: For now the conflicts are text conflicts. In the future this might be extended to deal with metadata conflicts too. I don't think anyone was thinking about rename/rename conficts... > > I am unclear on what your "unmerged" (M) status means. > > Probably 'conflict. That was my best guess too. Can anyone say more definitely? -- Eric S. Raymond From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthieu Moy Subject: Re: Status of all files (was: Re: How can I tell if a file is ignored by git? Date: Fri, 09 Apr 2010 16:23:11 +0200 Message-ID: References: <20100409040434.8602620CBBC@snark.thyrsus.com> <20100409113248.GB27353@thyrsus.com> <20100409140215.GB27899@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jakub Narebski , Jacob Helwig , Eric Raymond , git@vger.kernel.org To: esr@thyrsus.com X-From: git-owner@vger.kernel.org Fri Apr 09 16:23:33 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O0F7J-0002sE-9d for gcvg-git-2@lo.gmane.org; Fri, 09 Apr 2010 16:23:29 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752055Ab0DIOXW (ORCPT ); Fri, 9 Apr 2010 10:23:22 -0400 Received: from mx1.imag.fr ([129.88.30.5]:45025 "EHLO shiva.imag.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750810Ab0DIOXV (ORCPT ); Fri, 9 Apr 2010 10:23:21 -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 o39EIWVo022378 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 9 Apr 2010 16:18:32 +0200 Received: from bauges.imag.fr ([129.88.43.5]) by mail-veri.imag.fr with esmtp (Exim 4.69) (envelope-from ) id 1O0F71-0000h7-Lz; Fri, 09 Apr 2010 16:23:11 +0200 In-Reply-To: <20100409140215.GB27899@thyrsus.com> (Eric Raymond's message of "Fri\, 9 Apr 2010 10\:02\:15 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.1.93 (gnu/linux) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (shiva.imag.fr [129.88.30.5]); Fri, 09 Apr 2010 16:18:33 +0200 (CEST) X-IMAG-MailScanner-Information: Please contact MI2S MIM for more information X-MailScanner-ID: o39EIWVo022378 X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-SpamCheck: X-IMAG-MailScanner-From: matthieu.moy@grenoble-inp.fr MailScanner-NULL-Check: 1271427513.69157@0NL9Qqg8CXMHNJtRvXACjw Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Eric Raymond writes: > (The ls-files -t codes need better documentation. If I get detailed enough > answers, I will write some.) http://thread.gmane.org/gmane.comp.version-control.git/126516 In short, "git ls-files -t" was written long ago, never tested, and probably mostly used by no one. It has a very strange behavior, it's not just the doc. I'd advise against using it. "git status --porcelain" is probably what you want: --porcelain Give the output in a stable, easy-to-parse format for scripts. Currently this is identical to --short output, but is guaranteed not to change in the future, making it safe for scripts. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jakub Narebski Subject: Re: Status of all files (was: Re: How can I tell if a file is ignored by git? Date: Fri, 9 Apr 2010 16:50:41 +0200 Message-ID: <201004091650.43326.jnareb@gmail.com> References: <20100409040434.8602620CBBC@snark.thyrsus.com> <20100409140215.GB27899@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Jacob Helwig , Eric Raymond , git@vger.kernel.org To: Eric Raymond X-From: git-owner@vger.kernel.org Fri Apr 09 16:51:08 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O0FY0-0002bb-MJ for gcvg-git-2@lo.gmane.org; Fri, 09 Apr 2010 16:51:05 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753760Ab0DIOuy (ORCPT ); Fri, 9 Apr 2010 10:50:54 -0400 Received: from mail-fx0-f223.google.com ([209.85.220.223]:58198 "EHLO mail-fx0-f223.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753341Ab0DIOuw (ORCPT ); Fri, 9 Apr 2010 10:50:52 -0400 Received: by fxm23 with SMTP id 23so2891505fxm.21 for ; Fri, 09 Apr 2010 07:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id; bh=7vAfccJDKrVgtBIR2plvaG4N2Y9NTWieSMUTANq95PE=; b=Wmoo5KD0NsOqCAE9eEf12nwlYxF2hCdFsK5NK059rhcWyVU7c3QNt5qGw83kf3LQOo fWCAFdktVW/EXYpplhVLrO/TAfuOLKkJLzWBaXsZyDRCqkyW31Y5dMGTwH2vST5/3PyM mDYwrFlhnnuUEC54h2gwrYGW/bcKWkE5GsRQc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id; b=kV/u0T1mcFtpwBv1Xq90yS7grpy7LnvjNbb2DpVIXpo+j2+g9JNKJsbBRz9VbjmJhn aOZG6unfzOJK7E35Z83yiD0VULkW8Lox4zp4RFVdhvTJJTsppIW0pOWw++OX7quK+0uu ZwjRH8xXaNRYfNG+gpM0MZYedxrTS4Xz5Nt4g= Received: by 10.223.5.207 with SMTP id 15mr201603faw.6.1270824651053; Fri, 09 Apr 2010 07:50:51 -0700 (PDT) Received: from [192.168.1.13] (abvc167.neoplus.adsl.tpnet.pl [83.8.200.167]) by mx.google.com with ESMTPS id 16sm791735fxm.4.2010.04.09.07.50.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Apr 2010 07:50:50 -0700 (PDT) User-Agent: KMail/1.9.3 In-Reply-To: <20100409140215.GB27899@thyrsus.com> Content-Disposition: inline Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Fri, 9 Apr 2010, Eric Raymond wrote: > Jakub Narebski : > > There is also > > > > git status --short > > Not documented in my installed version, 1.6.3.3. Where can I go in the > repo to read about this? It was *documented* in git version 1.7.0 in 7c9f703 (commit: support alternate status formats, 2009-09-05) I am running git version 1.7.0.1. BTW. it is only since git 1.7.0 that "git status" is no longer "git commit --dry-run"... and has sane behaviour wrt. specifying paths. [...] > > > > > > 'needs-update The file has not been edited by the user, but there is > > > a more recent version on the current branch stored > > > in the master file. > > > > Needs *update* looks like it came from centralized VCS like CVS and > > Subversion, where you use update-the-commit method. You can't say > > that HEAD version is more recent that working file... > > > > The rought equivalent would be that upstream branch for current > > branch (e.g. 'origin/master' can be upstream for 'master' branch) is > > in fast-forward state i.e. current branch is direct ancestor of > > corresponding upstream branch, and the file was modified upstream. > > Agreed. But there's no way to tell that this is the case without > doing a pull operation or otherwise querying origin, and I'm > not going to do that. > > Explanation: My general rule for DVCS back ends is that the status commands > aren't allowed to do network operations, and it's OK for them not to > report a state code if that would be required. This is so VC will fully > support disconnected operation when the VCS does. > > I have, however, added a note to vc-git.el explaining that this is > possible if we ever teach the mode front end to behave differently when > it knows it has live Internet. I might do this in the future. > > > > > > > 'needs-merge The file has been edited by the user, and there is also > > > a more recent version on the current branch stored in > > > the master file. This state can only occur if locking > > > is not used for the file. > > > > This, like 'needs-update, looks like it is relevant only in > > update-the-commit workflow centralized VCS. > > Following your previous logic, I think it would make sense to set this if > we could detect that the upstream of the current branch has forward commits > touching this file. Again, this would require a network operation in the > general case. Actually it would not require network access, but it would require extra work, and equivalents of 'needs-update and 'needs-merge would not exist in all cases (in all situations). In Git you have remote-tracking branches, which are tracking where branches in remote repository point to. Since quite some time by default the reside in 'refs/remotes//' namespace, while ordinary local branches in 'refs/heads/' namespace. For example remote-tracking branch 'refs/remotes/origin/master', usually referred to in short as 'origin/master', tracks (follows) branch 'master' ('refs/heads/master') in remote 'origin'. Those branches might be out-of-date with respect to remote repository, and to update them you need network connection. Local branches can be created to "track" other branches, to base work on the other branches. In particular you need to create local branch which "tracks", or in other words has as 'upstream' some remote-tracking branch, as you cannot work on non-local branch (outside 'refs/heads/' namespace). Now, *if* you are on branch with some upstream, you can check without need for network operation whether "git pull" would do if there were no new changes in remote, which means what "git merge " would do (pull = fetch + merge). We can check if remote-tracking branch, which is upstream of current branch, modified current file. We can also check if remote-tracking branch is in fast-forwardable state wrt. current branch (the equivalent of 'needs-update state, I guess), or did remote-tracking branch diverged from current branch (the equivalent of 'needs-merge state, I guess). All this without need for network operation... but all this based on current information that might be stale. P.S. Simple "git checkout" would show if branches diverge, although it is meant for end user, not scripting. For example: $ git checkout Your branch and 'gitweb-kernel.org/gitweb-ml-v5' have diverged, and have 912 and 9 different commit(s) each, respectively. P.P.S. When documentation is insufficient, you can always as last resort take a look at git test suite, e.g. at t/t3000-ls-files* and t/t7508-status.sh -- Jakub Narebski Poland From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Raymond Subject: Re: Status of all files (was: Re: How can I tell if a file is ignored by git? Date: Fri, 9 Apr 2010 12:24:25 -0400 Organization: Eric Conspiracy Secret Labs Message-ID: <20100409162425.GA32575@thyrsus.com> References: <20100409040434.8602620CBBC@snark.thyrsus.com> <20100409113248.GB27353@thyrsus.com> <20100409140215.GB27899@thyrsus.com> Reply-To: esr@thyrsus.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jakub Narebski , Jacob Helwig , Eric Raymond , git@vger.kernel.org To: Matthieu Moy X-From: git-owner@vger.kernel.org Fri Apr 09 18:24:35 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O0H0T-0002RA-M4 for gcvg-git-2@lo.gmane.org; Fri, 09 Apr 2010 18:24:34 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754283Ab0DIQY1 (ORCPT ); Fri, 9 Apr 2010 12:24:27 -0400 Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:56728 "EHLO snark.thyrsus.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751041Ab0DIQY0 (ORCPT ); Fri, 9 Apr 2010 12:24:26 -0400 Received: by snark.thyrsus.com (Postfix, from userid 23) id 83081475FEF; Fri, 9 Apr 2010 12:24:25 -0400 (EDT) Content-Disposition: inline In-Reply-To: X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.20 (2009-06-14) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Matthieu Moy : > Eric Raymond writes: > > > (The ls-files -t codes need better documentation. If I get detailed enough > > answers, I will write some.) > > http://thread.gmane.org/gmane.comp.version-control.git/126516 > > In short, "git ls-files -t" was written long ago, never tested, and > probably mostly used by no one. It has a very strange behavior, it's > not just the doc. I'd advise against using it. It sounds very much to me as though this feature should be scheduled for deletion. > "git status --porcelain" is probably what you want: > > --porcelain > Give the output in a stable, easy-to-parse format for > scripts. Currently this is identical to --short output, but > is guaranteed not to change in the future, making it safe > for scripts. Yes, this looks like what I would want, all right - if the status codes were actually *comprehensible*! We should tackle this right now, because VC is not the last front end that will need to parse the format and at least I am willing to patch your docs based on what I learn. Most of your other customers won't do that. I'm going to start a separate thread about this. -- Eric S. Raymond From mboxrd@z Thu Jan 1 00:00:00 1970 From: Junio C Hamano Subject: Re: Status of all files (was: Re: How can I tell if a file is ignored by git? Date: Fri, 09 Apr 2010 09:52:37 -0700 Message-ID: <7v8w8w36wa.fsf@alter.siamese.dyndns.org> References: <20100409040434.8602620CBBC@snark.thyrsus.com> <20100409113248.GB27353@thyrsus.com> <20100409140215.GB27899@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: esr@thyrsus.com, Jakub Narebski , Jacob Helwig , Eric Raymond , git@vger.kernel.org To: Matthieu Moy X-From: git-owner@vger.kernel.org Fri Apr 09 18:53:01 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O0HS0-0007zt-3u for gcvg-git-2@lo.gmane.org; Fri, 09 Apr 2010 18:53:00 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754457Ab0DIQwz (ORCPT ); Fri, 9 Apr 2010 12:52:55 -0400 Received: from a-pb-sasl-quonix.pobox.com ([208.72.237.25]:49172 "EHLO sasl.smtp.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752869Ab0DIQwy (ORCPT ); Fri, 9 Apr 2010 12:52:54 -0400 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 2631AA909C; Fri, 9 Apr 2010 12:52:52 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=to:cc:subject :references:from:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=IB3SuzY7jfm5BThnhKfXmZtNG90=; b=WGsdS+ myJ2o9jPb5Yqdb7U/N0L3iVckOBmZ+ksSjPu++oskgMtwddXVNjHNfFQQqCrY8Ja AN2al5+duV3tFpB25RZzngyZCo1w5O18gOn+GCShsv7DLUprufSw4+RxwmbvZ05M qUhcbcvkT7Mk3jfjmtLeih5FqskTvgDHV6fKE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=to:cc:subject :references:from:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=f0KJdy36LwmM6AM9pRpwpwt8tPkVSZyS nvAHhWNnJtZ9VIokOfBp7gxl8DvvLoBB9WgUMTERlantB2i+lw5Pyh8I/Lv81bXM jCmkewJ9xYxVwNlermZ4QyaFAERj3DxCWG78iCRNSjys16usQM9T9RZXe1Y308Hm Kv66Keax8CU= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id B410BA9092; Fri, 9 Apr 2010 12:52:45 -0400 (EDT) Received: from pobox.com (unknown [68.225.240.211]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id C559CA908D; Fri, 9 Apr 2010 12:52:38 -0400 (EDT) In-Reply-To: (Matthieu Moy's message of "Fri\, 09 Apr 2010 16\:23\:11 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) X-Pobox-Relay-ID: 525B90FE-43F8-11DF-B374-D033EE7EF46B-77302942!a-pb-sasl-quonix.pobox.com Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Matthieu Moy writes: > In short, "git ls-files -t" was written long ago, never tested, and > probably mostly used by no one. It was added primarily for Cogito, which is presumably dead by now. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Grace Subject: Re: Status of all files (was: Re: How can I tell if a file is ignored by git? Date: Fri, 9 Apr 2010 18:18:53 -0500 Message-ID: References: <20100409040434.8602620CBBC@snark.thyrsus.com> <20100409113248.GB27353@thyrsus.com> <20100409140215.GB27899@thyrsus.com> <20100409162425.GA32575@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Matthieu Moy , Jakub Narebski , Jacob Helwig , Eric Raymond , git@vger.kernel.org To: esr@thyrsus.com X-From: git-owner@vger.kernel.org Sat Apr 10 01:19:03 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O0NTa-0002Ji-5J for gcvg-git-2@lo.gmane.org; Sat, 10 Apr 2010 01:19:02 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754068Ab0DIXS5 convert rfc822-to-quoted-printable (ORCPT ); Fri, 9 Apr 2010 19:18:57 -0400 Received: from qw-out-2122.google.com ([74.125.92.26]:64002 "EHLO qw-out-2122.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753599Ab0DIXS5 convert rfc822-to-8bit (ORCPT ); Fri, 9 Apr 2010 19:18:57 -0400 Received: by qw-out-2122.google.com with SMTP id 8so1391804qwh.37 for ; Fri, 09 Apr 2010 16:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Lz8MczvAidrwgMto2vw32JrqECCWUzsSWUvZ8vkmzVw=; b=qwYdNlqTkuQ122jqMVowFGQGX2oIgNuGSE44ksL4+RMLJcaMQMEudYZDnfmR0SHD7r WXrxhR6asf40FrhHP2dp5VHPDkNxwNU4xx8eZI3eWkdETXWcZRtGsgt9UzwR8nWMpfId +Zn2SgrzL6JSveSy00WDtNbMKBoc5J69rqhdA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vMueYpumaXZDQ4MSIJD8RHAVexLUjLJBXD1K5tlGqCm4Myjan4c/PF9/BS25FZLkVc EYzFTGD9xT4IqEYoCRVf+NdpuFiJiYLw8+b1BGPXd/B8OpmuBtfVs/qbKU6jE/MvNott iJeagQX+PHUP0gerPa+jGVmvb0XJjdNDu+/98= Received: by 10.229.88.66 with HTTP; Fri, 9 Apr 2010 16:18:53 -0700 (PDT) In-Reply-To: Received: by 10.229.216.76 with SMTP id hh12mr1012928qcb.47.1270855133935; Fri, 09 Apr 2010 16:18:53 -0700 (PDT) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Eric, I am working on a similar program (not ready for announcing yet). I have not gotten to the part that would need this, but I would be happy to start planning that stage and work with you to make sure that this feature met both of our needs, and help write the documentation if need be. (Sorry for the double everyone in To/Cc, gmail defaulted to HTML email and it was rejected from the list. I had to To/Cc you all again so that Reply All from list members would work as expected.) Daniel http://www.doomstick.com On Fri, Apr 9, 2010 at 6:15 PM, Daniel Grace w= rote: > > Eric, > I am working on a similar program (not ready for announcing yet). I h= ave not gotten to the part that would need this, but I would be happy t= o start planning that stage and work with you to make sure that this fe= ature met both of our needs, and help write the documentation if need b= e. > Daniel > http://www.doomstick.com > > > On Fri, Apr 9, 2010 at 11:24 AM, Eric Raymond wrote= : >> >> Matthieu Moy : >> > Eric Raymond writes: >> > >> > > (The ls-files -t codes need better documentation. =A0If I get de= tailed enough >> > > answers, I will write some.) >> > >> > http://thread.gmane.org/gmane.comp.version-control.git/126516 >> > >> > In short, "git ls-files -t" was written long ago, never tested, an= d >> > probably mostly used by no one. It has a very strange behavior, it= 's >> > not just the doc. I'd advise against using it. >> >> It sounds very much to me as though this feature should be scheduled >> for deletion. >> >> > "git status --porcelain" is probably what you want: >> > >> > =A0 =A0 =A0 =A0--porcelain >> > =A0 =A0 =A0 =A0 =A0 =A0Give the output in a stable, easy-to-parse = format for >> > =A0 =A0 =A0 =A0 =A0 =A0scripts. Currently this is identical to --s= hort output, but >> > =A0 =A0 =A0 =A0 =A0 =A0is guaranteed not to change in the future, = making it safe >> > =A0 =A0 =A0 =A0 =A0 =A0for scripts. >> >> Yes, this looks like what I would want, all right - if the status >> codes were actually *comprehensible*! >> >> We should tackle this right now, because VC is not the last front en= d >> that will need to parse the format and at least I am willing to patc= h >> your docs based on what I learn. =A0Most of your other customers won= 't >> do that. >> >> I'm going to start a separate thread about this. >> -- >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Eric S. Raymond >> -- >> To unsubscribe from this list: send the line "unsubscribe git" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at =A0http://vger.kernel.org/majordomo-info.html > From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Raymond Subject: Re: Status of all files (was: Re: How can I tell if a file is ignored by git? Date: Fri, 9 Apr 2010 23:35:05 -0400 Organization: Eric Conspiracy Secret Labs Message-ID: <20100410033505.GB18634@thyrsus.com> References: <20100409040434.8602620CBBC@snark.thyrsus.com> <20100409113248.GB27353@thyrsus.com> <20100409140215.GB27899@thyrsus.com> <20100409162425.GA32575@thyrsus.com> Reply-To: esr@thyrsus.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Matthieu Moy , Jakub Narebski , Jacob Helwig , Eric Raymond , git@vger.kernel.org To: Daniel Grace X-From: git-owner@vger.kernel.org Sat Apr 10 05:35:15 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O0RTX-00007O-Fk for gcvg-git-2@lo.gmane.org; Sat, 10 Apr 2010 05:35:15 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755493Ab0DJDfJ (ORCPT ); Fri, 9 Apr 2010 23:35:09 -0400 Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]:38628 "EHLO snark.thyrsus.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754856Ab0DJDfI (ORCPT ); Fri, 9 Apr 2010 23:35:08 -0400 Received: by snark.thyrsus.com (Postfix, from userid 23) id 11DD2475FEF; Fri, 9 Apr 2010 23:35:05 -0400 (EDT) Content-Disposition: inline In-Reply-To: X-Eric-Conspiracy: There is no conspiracy User-Agent: Mutt/1.5.20 (2009-06-14) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Daniel Grace : > I am working on a similar program (not ready for announcing yet). I have not > gotten to the part that would need this, but I would be happy to start > planning that stage and work with you to make sure that this feature met > both of our needs, and help write the documentation if need be. I'm willing to cooperate. -- Eric S. Raymond From mboxrd@z Thu Jan 1 00:00:00 1970 From: Junio C Hamano Subject: Re: Status of all files (was: Re: How can I tell if a file is ignored by git? Date: Sat, 10 Apr 2010 12:07:15 -0700 Message-ID: <7vsk73w2ho.fsf@alter.siamese.dyndns.org> References: <20100409040434.8602620CBBC@snark.thyrsus.com> <20100409113248.GB27353@thyrsus.com> <864ojkx1un.fsf@red.stonehenge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: esr@thyrsus.com, Jacob Helwig , Eric Raymond , git@vger.kernel.org To: merlyn@stonehenge.com (Randal L. Schwartz) X-From: git-owner@vger.kernel.org Sat Apr 10 21:07:37 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O0g1m-00056Y-Bf for gcvg-git-2@lo.gmane.org; Sat, 10 Apr 2010 21:07:34 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752211Ab0DJTH3 (ORCPT ); Sat, 10 Apr 2010 15:07:29 -0400 Received: from a-pb-sasl-quonix.pobox.com ([208.72.237.25]:48008 "EHLO sasl.smtp.pobox.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752164Ab0DJTH2 (ORCPT ); Sat, 10 Apr 2010 15:07:28 -0400 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id D6B73A9C68; Sat, 10 Apr 2010 15:07:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=to:cc:subject :references:from:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=o2GaEDQQDlUF3ROLE66Kaczs5pg=; b=pFS4/t Jxb7lZ/IxtIMw96/uivqk2KNJNx0QI7BTCSeaX72tU4mHM5LZ7l7rYOGKnt1JiUk jGrx0k+64u6AurZxxFZJwXfK/1f18DsQEZk8WL3DeGUaWAY4Hc1q5P3WAzpszGZU kLQOASzWa3SADuSZrK6+6ACaORAbY4iVR4CxI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=to:cc:subject :references:from:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=V7NYfHDnlLRsJvMhSUQNDsKqhaKZM0n8 j0Ngz3XFkXEFoBz/9ntOizh/fnVdoDH/mQsJZHdLioZBfSDYQdbHe2eMDLRjbk2x WQay8o2H61NV4AHeOFsbffwCVo4duB6Amzw/MRBWy5sQj3LFCG1ry+JwX7nu/X/a 3LLGh7t+990= Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id 855BAA9C67; Sat, 10 Apr 2010 15:07:22 -0400 (EDT) Received: from pobox.com (unknown [68.225.240.211]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 9D412A9C65; Sat, 10 Apr 2010 15:07:16 -0400 (EDT) In-Reply-To: <864ojkx1un.fsf@red.stonehenge.com> (Randal L. Schwartz's message of "Fri\, 09 Apr 2010 05\:11\:12 -0700") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) X-Pobox-Relay-ID: 4AEC8F9E-44D4-11DF-B94F-D033EE7EF46B-77302942!a-pb-sasl-quonix.pobox.com Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: merlyn@stonehenge.com (Randal L. Schwartz) writes: > A lot of these don't make sense for git and other DVCS. I agree with you in principle, but not with the details in the example. > For example: > > Eric> 'needs-update The file has not been edited by the user, but there is > Eric> a more recent version on the current branch stored > Eric> in the master file. > > This makes sense only with a file-based VCS, not a tree-based VCS like > git. This isn't about file vs tree, but more about centralized vs distributed. In DVCS workflows "needs-update" as a concept does not even exist when you are working on a topic branch to perfect one thing and one thing only. You do not want to update only because somebody else did some work that may be totally unrelated to what you wanted to achieve on the current branch. I presume that many people use git in centralized workflow where they use only 'master' branch and "git pull ; work ; git commit; git push" are the only things they do. In that setting, "needs-update" may make sense. The VC backend implementation has to do "git fetch" to see if the origin has advanced. Almost the same comment applies to 'needs-merge', but the VC backend not only needs to worry about "file has been edited", but also "commits that touch the file has been made locally". > Eric> 'removed Scheduled to be deleted from the repository > Eric> on next commit. > > Not useful in git. Isn't "git rm removed" exactly "scheduled to be deleted"? > Eric> 'missing The file is not present in the file system, but the VC > Eric> system still tracks it. > > Not available in git. (If it's not a real file, it can't be tracked. :) Isn't "rm missing" exactly this? > Eric> 'ignored The file showed up in a dir-status listing with a flag > Eric> indicating the version-control system is ignoring it, > > Eric> 'unregistered The file is not under version control. > > These two would be identical in git. Ignored is a subset of Unregistered, no? Neither exists in the index (i.e. not tracked); ignored ones are covered by .gitignore and you need to force "git add" to start tracking them. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: Status of all files Date: Sun, 11 Apr 2010 00:12:33 +0200 Message-ID: <4BC0F7D1.6000003@gnu.org> References: <20100409040434.8602620CBBC@snark.thyrsus.com> <20100409113248.GB27353@thyrsus.com> <20100409140215.GB27899@thyrsus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jakub Narebski , Jacob Helwig , git@vger.kernel.org To: esr@thyrsus.com X-From: git-owner@vger.kernel.org Sun Apr 11 00:12:47 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O0iuz-0007pd-Ca for gcvg-git-2@lo.gmane.org; Sun, 11 Apr 2010 00:12:45 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752063Ab0DJWMk (ORCPT ); Sat, 10 Apr 2010 18:12:40 -0400 Received: from fg-out-1718.google.com ([72.14.220.153]:54448 "EHLO fg-out-1718.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751768Ab0DJWMj (ORCPT ); Sat, 10 Apr 2010 18:12:39 -0400 Received: by fg-out-1718.google.com with SMTP id 22so55523fge.1 for ; Sat, 10 Apr 2010 15:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=DDqFPQLHF3yPPpzt0YAmM37yJ+CQeqH7HxRFaZMrCfk=; b=pHhS2XP6F6TA9YAtr9WWVJD68ZXXYi5ZKJYn09/5hhMMSoQGCpMMvFhtefZfvwHlOO dg6KS21SN9V+ZnXSyusDQKEBneHhuEdmvF0ccJpJwJZDWcuaL6SD5A8ABh7R//5OPQ2k JOloVpG72qWD/nboDgS+ymnWJRXgJK+9tOZ8g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=dxFY9vczrpb8+dGwiLxYUWYeGwGoKJdRsiv8Otgeq9xxZgCfiIJGW3bo3eDZ6Gn/j2 jNJJY43GCxRq+NRUpwgW0uWQJs/S2kxJD/Kvy2cNox7sash8QZ9gAGyNhwYpv1wK7MXQ AwxeiGA0FHK9Hiart4IE+NdLktBcdByb97/Ak= Received: by 10.223.5.207 with SMTP id 15mr1734052faw.6.1270937556938; Sat, 10 Apr 2010 15:12:36 -0700 (PDT) Received: from yakj.usersys.redhat.com (s209p8.home.99maxprogres.cz [85.93.118.17]) by mx.google.com with ESMTPS id 19sm5792333fkr.39.2010.04.10.15.12.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 10 Apr 2010 15:12:35 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.3 In-Reply-To: <20100409140215.GB27899@thyrsus.com> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On 04/09/2010 04:02 PM, Eric Raymond wrote: >>> > > >>> > > 'needs-update The file has not been edited by the user, but there is >>> > > a more recent version on the current branch stored >>> > > in the master file. >> > >> > Needs*update* looks like it came from centralized VCS like CVS and >> > Subversion, where you use update-the-commit method. You can't say >> > that HEAD version is more recent that working file... >> > >> > The rought equivalent would be that upstream branch for current >> > branch (e.g. 'origin/master' can be upstream for 'master' branch) is >> > in fast-forward state i.e. current branch is direct ancestor of >> > corresponding upstream branch, and the file was modified upstream. > > Agreed. But there's no way to tell that this is the case without > doing a pull operation or otherwise querying origin, and I'm > not going to do that. You can query the origin _as it was on the last fetch_. If you are on branch X, the logic is as follows: - Let R be the value of configuration key branch.X.remote, - let M be the value of configuration key branch.X.merge, - for all values S of configuration key remote.R.fetch, - strip an initial + - if S is M:N, return N - if S is P/*:Q/* where P is a prefix of M, take M, replace this prefix with Q and return the result In the most common case you will have: - X = master - R = origin - M = refs/heads/master - one key S = +refs/heads/*:refs/remotes/origin/* so the prefix "refs/heads/" is replaced with "refs/remotes/origin/" and the result is refs/remotes/origin/master. Paolo From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff King Subject: Re: Status of all files Date: Sun, 11 Apr 2010 06:25:35 -0400 Message-ID: <20100411102534.GC20484@coredump.intra.peff.net> References: <20100409040434.8602620CBBC@snark.thyrsus.com> <20100409113248.GB27353@thyrsus.com> <20100409140215.GB27899@thyrsus.com> <4BC0F7D1.6000003@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: esr@thyrsus.com, Jakub Narebski , Jacob Helwig , git@vger.kernel.org To: Paolo Bonzini X-From: git-owner@vger.kernel.org Sun Apr 11 12:26:12 2010 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1O0uMj-0000EC-0i for gcvg-git-2@lo.gmane.org; Sun, 11 Apr 2010 12:26:09 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751688Ab0DKK0E (ORCPT ); Sun, 11 Apr 2010 06:26:04 -0400 Received: from peff.net ([208.65.91.99]:40565 "EHLO peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751538Ab0DKK0B (ORCPT ); Sun, 11 Apr 2010 06:26:01 -0400 Received: (qmail 3102 invoked by uid 107); 11 Apr 2010 10:26:01 -0000 Received: from coredump.intra.peff.net (HELO coredump.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.40) with (AES128-SHA encrypted) SMTP; Sun, 11 Apr 2010 06:26:01 -0400 Received: by coredump.intra.peff.net (sSMTP sendmail emulation); Sun, 11 Apr 2010 06:25:35 -0400 Content-Disposition: inline In-Reply-To: <4BC0F7D1.6000003@gnu.org> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Sun, Apr 11, 2010 at 12:12:33AM +0200, Paolo Bonzini wrote: > >Agreed. But there's no way to tell that this is the case without > >doing a pull operation or otherwise querying origin, and I'm > >not going to do that. > > You can query the origin _as it was on the last fetch_. > > If you are on branch X, the logic is as follows: > > - Let R be the value of configuration key branch.X.remote, > - let M be the value of configuration key branch.X.merge, > - for all values S of configuration key remote.R.fetch, > - strip an initial + > - if S is M:N, return N > - if S is P/*:Q/* where P is a prefix of M, take M, replace this > prefix with Q and return the result > > In the most common case you will have: > > - X = master > - R = origin > - M = refs/heads/master > - one key S = +refs/heads/*:refs/remotes/origin/* > > so the prefix "refs/heads/" is replaced with "refs/remotes/origin/" > and the result is refs/remotes/origin/master. BTW, this procedure is complex enough that we have exposed it via a plumbing interface: $ git for-each-ref --format='%(upstream)' refs/heads/master refs/remotes/origin/master which does all of the correct magic internally. -Peff