{"thread":{"id":"23387","subject":"How can I tell if a file is ignored by git?","startedAt":"2010-04-09T04:04:34Z","lastAt":"2010-04-11T10:25:35Z","messageCount":19,"participants":["Eric Raymond","Jacob Helwig","Ramkumar Ramachandra","Ævar Arnfjörð Bjarmason","Randal L. Schwartz","Jakub Narebski","Matthieu Moy","Junio C Hamano","Daniel Grace","Paolo Bonzini","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"139000","messageId":"20100409040434.8602620CBBC@snark.thyrsus.com","threadId":"23387","inReplyTo":null,"subject":"How can I tell if a file is ignored by git?","fromName":"Eric Raymond","fromEmail":"esr@snark.thyrsus.com","sentAt":"2010-04-09T04:04:34Z","receivedAt":"2010-04-09T04:04:34Z","isPatch":false,"sender":{"key":"esr@snark.thyrsus.com","avatar":null},"body":"I'm planning some work on Emacs VC mode.\n\nI need a command I can run on a path to tell if it's ignored by git.\n-- \n\t\tEric S. Raymond\n\nIf gun laws in fact worked, the sponsors of this type of legislation\nshould have no difficulty drawing upon long lists of examples of\ncriminal acts reduced by such legislation. That they cannot do so\nafter a century and a half of trying -- that they must sweep under the\nrug the southern attempts at gun control in the 1870-1910 period, the\nnortheastern attempts in the 1920-1939 period, the attempts at both\nFederal and State levels in 1965-1976 -- establishes the repeated,\ncomplete and inevitable failure of gun laws to control serious crime.\n -- Senator Orrin Hatch, in a 1982 Senate Report\n"},{"id":"139001","messageId":"j2z8c9a061004082110se894f925i80c1389cd4e247f@mail.gmail.com","threadId":"23387","inReplyTo":"20100409040434.8602620CBBC@snark.thyrsus.com","subject":"Re: How can I tell if a file is ignored by git?","fromName":"Jacob Helwig","fromEmail":"jacob.helwig@gmail.com","sentAt":"2010-04-09T04:10:49Z","receivedAt":"2010-04-09T04:10:49Z","isPatch":false,"sender":{"key":"jacob.helwig@gmail.com","avatar":"https://avatars.githubusercontent.com/u/14557?v=4"},"body":"On Thu, Apr 8, 2010 at 21:04, Eric Raymond wrote:\n> I'm planning some work on Emacs VC mode.\n>\n> I need a command I can run on a path to tell if it's ignored by git.\n\nWhat about a variant of:\n git ls-files -i -o --exclude-standard\n"},{"id":"139002","messageId":"w2hf3271551004082150x620aa21az72b7254f57fbc3f5@mail.gmail.com","threadId":"23387","inReplyTo":"20100409040434.8602620CBBC@snark.thyrsus.com","subject":"Re: How can I tell if a file is ignored by git?","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-04-09T04:50:13Z","receivedAt":"2010-04-09T04:50:13Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\n> I'm planning some work on Emacs VC mode.\n\nI personally use Magit [1]. Just thought you might want to look at it.\n\n-- Ram\n\n[1] http://zagadka.vm.bytemark.co.uk/magit/\n"},{"id":"139003","messageId":"w2i51dd1af81004082201j81a2758di2e430785a72a5b03@mail.gmail.com","threadId":"23387","inReplyTo":"w2hf3271551004082150x620aa21az72b7254f57fbc3f5@mail.gmail.com","subject":"Re: How can I tell if a file is ignored by git?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-04-09T05:01:46Z","receivedAt":"2010-04-09T05:01:46Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, Apr 9, 2010 at 04:50, Ramkumar Ramachandra wrote:\n> I personally use Magit [1]. Just thought you might want to look at it.\n\nEric might be a bit too personally invested vc.el at this point :)\n\nBut yeah, magit is great, unlike vc-dir and vc it makes really good\nuse of Git's index & stash features. Instead of staging individual\nfiles for commit you stage chunks, the quality and granularity of my\ncommits has gone up since I switched to it from vc due to that.\n\nBut to help with the original question: magit has an ignore feature\nbut it doesn't check whether something is ignored, it just counts on\nyou not ignoring already ignored stuff because it isn't displayed to\nyou.\n\nDepending on how you're planning to implement .gitignore support you\nmight want to go this route.\n"},{"id":"139026","messageId":"20100409105015.GA27353@thyrsus.com","threadId":"23387","inReplyTo":"w2i51dd1af81004082201j81a2758di2e430785a72a5b03@mail.gmail.com","subject":"Re: How can I tell if a file is ignored by git?","fromName":"Eric Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2010-04-09T10:50:15Z","receivedAt":"2010-04-09T10:50:15Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Ævar Arnfjörð Bjarmason :\n> On Fri, Apr 9, 2010 at 04:50, Ramkumar Ramachandra wrote:\n> > I personally use Magit [1]. Just thought you might want to look at it.\n> \n> Eric might be a bit too personally invested vc.el at this point :)\n\nWell, there's that, and then there's the fact that I really do use\nmultiple VCSes. Consistent interface for all of them -> win. \n-- \n\t\tEric S. Raymond\n"},{"id":"139028","messageId":"20100409113248.GB27353@thyrsus.com","threadId":"23387","inReplyTo":"j2z8c9a061004082110se894f925i80c1389cd4e247f@mail.gmail.com","subject":"Status of all files (was: Re: How can I tell if a file is ignored by git?","fromName":"Eric Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2010-04-09T11:32:48Z","receivedAt":"2010-04-09T11:32:48Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Jacob Helwig :\n> On Thu, Apr 8, 2010 at 21:04, Eric Raymond wrote:\n> > I'm planning some work on Emacs VC mode.\n> >\n> > I need a command I can run on a path to tell if it's ignored by git.\n> \n> What about a variant of:\n> git ls-files -i -o --exclude-standard\n\nThat will do nicely, thank you.\n\nThere could be something better. Emacs VC mode, and other similar\nfront ends, would be greatly aided by a command that lists all files,\neach with a status code it can understand. Our canonical list\n(omitting two that apply only to locking systems) is:\n\n 'up-to-date The working file is unmodified with respect to the\n latest version on the current branch, and not locked.\n\n 'edited The working file has been edited by the user.\n\n 'needs-update The file has not been edited by the user, but there is\n a more recent version on the current branch stored\n in the master file.\n\n 'needs-merge The file has been edited by the user, and there is also\n a more recent version on the current branch stored in\n the master file. This state can only occur if locking\n is not used for the file.\n\n 'added Scheduled to go into the repository on the next commit.\n\n 'removed Scheduled to be deleted from the repository on next commit.\n\n 'conflict The file contains conflicts as the result of a merge.\n\n 'missing The file is not present in the file system, but the VC\n system still tracks it.\n\n 'ignored The file showed up in a dir-status listing with a flag\n indicating the version-control system is ignoring it,\n\n 'unregistered The file is not under version control.\n\nThe -t mode of ls-files appears to be almost what is wanted, but not quite.\n(Among other things, it does not list ignored files.) I request comment\non some related questions:\n\n1. How do these statuses map to git terminology? My tentative map, in terms \nof git file-list -t codes, is\n\nup-to-date = H?\nedited = C\nneeds-update = no equivalent\nneeds-merge = no equivalent\nadded = no equivalent\nremoved = K\nconflict = no equivalent\nmissing = R\nignored = no equivalent\nunregistered = no equivalent\n\nI am unclear on what your \"unmerged\" (M) status means.\n\n2. I've played with various option combinations, but I can't seem to find one\nthat lists these codes for all files. Is there one?\n\n3. Is the use case for -t such that it would make sense to modify it so\nit does a complete listing?\n\n4. If the answer to question 3 is 'yes', is there some Emacs user here\nwho already knows git internals and would be willing to do this in\norder to help VC be faster and more effective? I would handle the VC\nend, of course.\n-- \n\t\tEric S. Raymond\n"},{"id":"139031","messageId":"864ojkx1un.fsf@red.stonehenge.com","threadId":"23387","inReplyTo":"20100409113248.GB27353@thyrsus.com","subject":"Re: Status of all files (was: Re: How can I tell if a file is ignored by git?","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2010-04-09T12:11:12Z","receivedAt":"2010-04-09T12:11:12Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Eric\" == Eric Raymond writes:\n\nEric> There could be something better. Emacs VC mode, and other similar\nEric> front ends, would be greatly aided by a command that lists all files,\nEric> each with a status code it can understand. Our canonical list\nEric> (omitting two that apply only to locking systems) is:\n\nA lot of these don't make sense for git and other DVCS. How have\nhg and bzr interpreted these \"canonical\" states?\n\nFor example:\n\nEric> 'needs-update The file has not been edited by the user, but there is\nEric> a more recent version on the current branch stored\nEric> in the master file.\n\nThis makes sense only with a file-based VCS, not a tree-based VCS like\ngit.\n\nEric> 'needs-merge The file has been edited by the user, and there is also\nEric> a more recent version on the current branch stored in\nEric> the master file. This state can only occur if locking\nEric> is not used for the file.\n\nDitto.\n\nEric> 'removed Scheduled to be deleted from the repository\nEric> on next commit.\n\nNot useful in git.\n\nEric> 'missing The file is not present in the file system, but the VC\nEric> system still tracks it.\n\nNot available in git. (If it's not a real file, it can't be tracked. :)\n\nEric> 'ignored The file showed up in a dir-status listing with a flag\nEric> indicating the version-control system is ignoring it,\n\nEric> 'unregistered The file is not under version control.\n\nThese two would be identical in git.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nSmalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.\nSee http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion\n"},{"id":"139035","messageId":"m3sk74hjkg.fsf@localhost.localdomain","threadId":"23387","inReplyTo":"20100409113248.GB27353@thyrsus.com","subject":"Re: Status of all files (was: Re: How can I tell if a file is ignored by git?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-09T12:56:09Z","receivedAt":"2010-04-09T12:56:09Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Eric Raymond writes:\n\n> Jacob Helwig :\n> > On Thu, Apr 8, 2010 at 21:04, Eric Raymond wrote:\n> > > I'm planning some work on Emacs VC mode.\n> > >\n> > > I need a command I can run on a path to tell if it's ignored by git.\n> > \n> > What about a variant of:\n> > git ls-files -i -o --exclude-standard\n> \n> That will do nicely, thank you.\n> \n> There could be something better. Emacs VC mode, and other similar\n> front ends, would be greatly aided by a command that lists all files,\n> each with a status code it can understand.\n\nThere is also\n\n git status --short\n\n> Our canonical list (omitting two that apply only to locking systems)\n> is:\n> \n> 'up-to-date The working file is unmodified with respect to the\n> latest version on the current branch, and not locked.\n\nIn Git you don't have locking, but you have three versions: in the\nworking area (the working file), in the index, and latest version on\nthe current branch (the HEAD version).\n\nSo 'up-to-date in Git would probably mean working tree = cached = HEAD\nversion.\n\n> \n> 'edited The working file has been edited by the user.\n\nDoes this include stat-dirty files, i.e. if file has been modified\n(mtime), but the contents is the same in working file and in HEAD\nversion? See also 'git update-index --refresh' etc.\n\n> \n> 'needs-update The file has not been edited by the user, but there is\n> a more recent version on the current branch stored\n> in the master file.\n\nNeeds *update* looks like it came from centralized VCS like CVS and\nSubversion, where you use update-the-commit method. You can't say\nthat HEAD version is more recent that working file...\n\nThe rought equivalent would be that upstream branch for current branch\n(e.g. 'origin/master' can be upstream for 'master' branch) is in\nfast-forward state i.e. current branch is direct ancestor of\ncorresponding upstream branch, and the file was modified upstream.\n\n> \n> 'needs-merge The file has been edited by the user, and there is also\n> a more recent version on the current branch stored in\n> the master file. This state can only occur if locking\n> is not used for the file.\n\nThis, like 'needs-update, looks like it is relevant only in\nupdate-the-commit workflow centralized VCS.\n\n> \n> 'added Scheduled to go into the repository on the next commit.\n> \n> 'removed Scheduled to be deleted from the repository on next commit.\n> \n> 'conflict The file contains conflicts as the result of a merge.\n\nNote that with Git you can have other merge conflict than simple\nCONFLICT(contents). With CONFLICT(rename/rename) for example the file\nwould not contain textual conflict, so e.g. it won't have conflict\nmarkers, etc.\n\n> \n> 'missing The file is not present in the file system, but the VC\n> system still tracks it.\n\nNote that file might be missing only in working directory, and can be\nmissing both in working directory and the index (staging area).\n\n> \n> 'ignored The file showed up in a dir-status listing with a flag\n> indicating the version-control system is ignoring it,\n> \n> 'unregistered The file is not under version control.\n\n[...]\n> I am unclear on what your \"unmerged\" (M) status means.\n\nProbably 'conflict.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"139036","messageId":"20100409132037.GA27899@thyrsus.com","threadId":"23387","inReplyTo":"864ojkx1un.fsf@red.stonehenge.com","subject":"Re: Status of all files (was: Re: How can I tell if a file is ignored by git?","fromName":"Eric Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2010-04-09T13:20:37Z","receivedAt":"2010-04-09T13:20:37Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Randal L. Schwartz :\n> A lot of these don't make sense for git and other DVCS. How have\n> hg and bzr interpreted these \"canonical\" states?\n\nThat asks the question the wrong way around. These state codes\nare used to change how VC *itself* performs when you fire various\ncommands; the VCSes called by the VC back ends never have to\n'interpret' them.\n\nIt is not expected that every VCS will report all of them; in\nparticular, as you say, some only make sense in locking systems. \nWhen VC knows it's dealing with a merging system, it will never go\ndown a logic path where a locking-related state is checked for.\n\nI deleted two of the locking-system-only states from what you saw, but\nmay have missed others; I don't completely understand all the states,\nbecause at least eleven other people hacked on VC during the 15 years\nI was doing other things and added several that were not in my\noriginal design.\n\n(There is some excuse for this. Emacs VC is probably unique in that\nits ontology has to be rich enough to accomodate *every VCS there\nis*. Nothing else even attempts that, AFAIK.)\n\nBut to answer your question at least in part, here is a piece of code\nmapping status codes from Mercurial's hg status -A command to Emacs\nstate codes.\n\n (when (eq 0 status)\n (when (null (string-match \".*: No such file or directory$\" out))\n (let ((state (aref out 0)))\n (cond\n ((eq state ?=) 'up-to-date)\n ((eq state ?A) 'added)\n ((eq state ?M) 'edited)\n ((eq state ?I) 'ignored)\n ((eq state ?R) 'removed)\n ((eq state ?!) 'missing)\n ((eq state ??) 'unregistered)\n ((eq state ?C) 'up-to-date) ;; Older mercurials use this\n (t 'up-to-date)))))))\n\nThis is failing to report at least one interesting state, \nwhich is 'conflict. But otherwise it looks pretty complete.\n\nWhat I'm really looking for is a git functional equivalent of hg status -A.\nThe git backend presently uses diff-index and interprets the output in\na way that I fear is rather brittle.\n\nI'm inclined to think you are right that 'need-update and 'need-merge\ndon't make any sense in a tree-oriented VCS. On the other hand, SVN \nand Monotone both report them. On the gripping hand, I'm not certain these\nqualify as \"tree-oriented\" in quite as strong a sense as hg and git do.\nI need to understand this better.\n\nIf nothing else, perhaps this discussion will lead to me being able to\ndocument Emacs statuses more completely. There is a fair amount of\nmurk around them now, because the mode did a lot of growing by\naccretion that I have not completely cleaned up yet.\n\n> Eric> 'removed Scheduled to be deleted from the repository\n> Eric> on next commit.\n> \n> Not useful in git.\n\nI disagree. At least, git status reports \"removed\" files before a commit.\nThis seems like the logical state for a file after it has been subjected \nto \"git rm' but before commit.\n \n> Eric> 'missing The file is not present in the file system, but the VC\n> Eric> system still tracks it.\n> \n> Not available in git. (If it's not a real file, it can't be tracked. :)\n\nWhat about a file that has been deleted from the working copy with ordinary\nrm (as opposed to git rm) so it's still in the index? Wouldn't that qualify?\n\n> Eric> 'ignored The file showed up in a dir-status listing with a flag\n> Eric> indicating the version-control system is ignoring it,\n> \n> Eric> 'unregistered The file is not under version control.\n> \n> These two would be identical in git.\n\nCertainly not. If I have \"*.o\" in my .gitignore, and two untracked files\nfoo.c and foo.o in my directory, both are unregistered, but only\nfoo.o is ignored. Emacs wants to see foo.c -> 'unregistered but \nfoo.o -> 'ignored.\n-- \n\t\tEric S. Raymond\n"},{"id":"139037","messageId":"20100409140215.GB27899@thyrsus.com","threadId":"23387","inReplyTo":"m3sk74hjkg.fsf@localhost.localdomain","subject":"Re: Status of all files (was: Re: How can I tell if a file is ignored by git?","fromName":"Eric Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2010-04-09T14:02:15Z","receivedAt":"2010-04-09T14:02:15Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Jakub Narebski :\n> There is also\n> \n> git status --short\n\nNot documented in my installed version, 1.6.3.3. Where can I go in the\nrepo to read about this?\n\n> > Our canonical list (omitting two that apply only to locking systems)\n> > is:\n> > \n> > 'up-to-date The working file is unmodified with respect to the\n> > latest version on the current branch, and not locked.\n> \n> In Git you don't have locking, but you have three versions: in the\n> working area (the working file), in the index, and latest version on\n> the current branch (the HEAD version).\n> \n> So 'up-to-date in Git would probably mean working tree = cached = HEAD\n> version.\n\nYes, that was what I thought. Is this what ls-files is reporting as 'H'? \n\n(The ls-files -t codes need better documentation. If I get detailed enough\nanswers, I will write some.)\n \n> > \n> > 'edited The working file has been edited by the user.\n> \n> Does this include stat-dirty files, i.e. if file has been modified\n> (mtime), but the contents is the same in working file and in HEAD\n> version?\n\nNo, it does not. Thank you for asking that question, I have just\nadded a note about this to the VC code exactly where it will do the\nmost good.\n\n> > \n> > 'needs-update The file has not been edited by the user, but there is\n> > a more recent version on the current branch stored\n> > in the master file.\n> \n> Needs *update* looks like it came from centralized VCS like CVS and\n> Subversion, where you use update-the-commit method. You can't say\n> that HEAD version is more recent that working file...\n> \n> The rought equivalent would be that upstream branch for current\n> branch (e.g. 'origin/master' can be upstream for 'master' branch) is\n> in fast-forward state i.e. current branch is direct ancestor of\n> corresponding upstream branch, and the file was modified upstream.\n\nAgreed. But there's no way to tell that this is the case without \ndoing a pull operation or otherwise querying origin, and I'm\nnot going to do that.\n\nExplanation: My general rule for DVCS back ends is that the status commands\naren't allowed to do network operations, and it's OK for them not to\nreport a state code if that would be required. This is so VC will fully\nsupport disconnected operation when the VCS does.\n\nI have, however, added a note to vc-git.el explaining that this is\npossible if we ever teach the mode front end to behave differently when\nit knows it has live Internet. I might do this in the future.\n \n> > \n> > 'needs-merge The file has been edited by the user, and there is also\n> > a more recent version on the current branch stored in\n> > the master file. This state can only occur if locking\n> > is not used for the file.\n> \n> This, like 'needs-update, looks like it is relevant only in\n> update-the-commit workflow centralized VCS.\n\nFollowing your previous logic, I think it would make sense to set this if \nwe could detect that the upstream of the current branch has forward commits \ntouching this file. Again, this would require a network operation in the\ngeneral case.\n\n> > 'conflict The file contains conflicts as the result of a merge.\n> \n> Note that with Git you can have other merge conflict than simple\n> CONFLICT(contents). With CONFLICT(rename/rename) for example the file\n> would not contain textual conflict, so e.g. it won't have conflict\n> markers, etc.\n\nIt is unclear what Emacs wants in this situation; I will try to find out.\nThe documentation says this:\n\n For now the conflicts are text conflicts. In the\n future this might be extended to deal with metadata\n conflicts too.\n\nI don't think anyone was thinking about rename/rename conficts...\n \n> > I am unclear on what your \"unmerged\" (M) status means.\n> \n> Probably 'conflict.\n\nThat was my best guess too. Can anyone say more definitely?\n-- \n\t\tEric S. Raymond\n"},{"id":"139038","messageId":"vpqy6gw7lio.fsf@bauges.imag.fr","threadId":"23387","inReplyTo":"20100409140215.GB27899@thyrsus.com","subject":"Re: Status of all files (was: Re: How can I tell if a file is ignored by git?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2010-04-09T14:23:11Z","receivedAt":"2010-04-09T14:23:11Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Eric Raymond writes:\n\n> (The ls-files -t codes need better documentation. If I get detailed enough\n> answers, I will write some.)\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/126516\n\nIn short, \"git ls-files -t\" was written long ago, never tested, and\nprobably mostly used by no one. It has a very strange behavior, it's\nnot just the doc. I'd advise against using it.\n\n\"git status --porcelain\" is probably what you want:\n\n --porcelain\n Give the output in a stable, easy-to-parse format for\n scripts. Currently this is identical to --short output, but\n is guaranteed not to change in the future, making it safe\n for scripts.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"139041","messageId":"201004091650.43326.jnareb@gmail.com","threadId":"23387","inReplyTo":"20100409140215.GB27899@thyrsus.com","subject":"Re: Status of all files (was: Re: How can I tell if a file is ignored by git?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-04-09T14:50:41Z","receivedAt":"2010-04-09T14:50:41Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Fri, 9 Apr 2010, Eric Raymond wrote:\n> Jakub Narebski :\n> > There is also\n> > \n> > git status --short\n> \n> Not documented in my installed version, 1.6.3.3. Where can I go in the\n> repo to read about this?\n\nIt was *documented* in git version 1.7.0 in \n 7c9f703 (commit: support alternate status formats, 2009-09-05)\nI am running git version 1.7.0.1.\n\nBTW. it is only since git 1.7.0 that \"git status\" is no longer\n\"git commit --dry-run\"... and has sane behaviour wrt. specifying paths.\n\n[...]\n> > > \n> > > 'needs-update The file has not been edited by the user, but there is\n> > > a more recent version on the current branch stored\n> > > in the master file.\n> > \n> > Needs *update* looks like it came from centralized VCS like CVS and\n> > Subversion, where you use update-the-commit method. You can't say\n> > that HEAD version is more recent that working file...\n> > \n> > The rought equivalent would be that upstream branch for current\n> > branch (e.g. 'origin/master' can be upstream for 'master' branch) is\n> > in fast-forward state i.e. current branch is direct ancestor of\n> > corresponding upstream branch, and the file was modified upstream.\n> \n> Agreed. But there's no way to tell that this is the case without \n> doing a pull operation or otherwise querying origin, and I'm\n> not going to do that.\n> \n> Explanation: My general rule for DVCS back ends is that the status commands\n> aren't allowed to do network operations, and it's OK for them not to\n> report a state code if that would be required. This is so VC will fully\n> support disconnected operation when the VCS does.\n> \n> I have, however, added a note to vc-git.el explaining that this is\n> possible if we ever teach the mode front end to behave differently when\n> it knows it has live Internet. I might do this in the future.\n> \n> > > \n> > > 'needs-merge The file has been edited by the user, and there is also\n> > > a more recent version on the current branch stored in\n> > > the master file. This state can only occur if locking\n> > > is not used for the file.\n> > \n> > This, like 'needs-update, looks like it is relevant only in\n> > update-the-commit workflow centralized VCS.\n> \n> Following your previous logic, I think it would make sense to set this if \n> we could detect that the upstream of the current branch has forward commits \n> touching this file. Again, this would require a network operation in the\n> general case.\n\nActually it would not require network access, but it would require extra\nwork, and equivalents of 'needs-update and 'needs-merge would not exist\nin all cases (in all situations).\n\nIn Git you have remote-tracking branches, which are tracking where \nbranches in remote repository point to. Since quite some time by default\nthe reside in 'refs/remotes//' namespace, while ordinary local\nbranches in 'refs/heads/' namespace. For example remote-tracking branch\n'refs/remotes/origin/master', usually referred to in short as \n'origin/master', tracks (follows) branch 'master' ('refs/heads/master')\nin remote 'origin'. Those branches might be out-of-date with respect\nto remote repository, and to update them you need network connection.\n\nLocal branches can be created to \"track\" other branches, to base work\non the other branches. In particular you need to create local branch\nwhich \"tracks\", or in other words has as 'upstream' some remote-tracking\nbranch, as you cannot work on non-local branch (outside 'refs/heads/'\nnamespace).\n\nNow, *if* you are on branch with some upstream, you can check without\nneed for network operation whether \"git pull\" would do if there were\nno new changes in remote, which means what \"git merge \" would\ndo (pull = fetch + merge).\n\nWe can check if remote-tracking branch, which is upstream of current\nbranch, modified current file. We can also check if remote-tracking\nbranch is in fast-forwardable state wrt. current branch (the equivalent\nof 'needs-update state, I guess), or did remote-tracking branch diverged\nfrom current branch (the equivalent of 'needs-merge state, I guess).\nAll this without need for network operation... but all this based on\ncurrent information that might be stale.\n\n\nP.S. Simple \"git checkout\" would show if branches diverge, although\nit is meant for end user, not scripting. For example:\n\n $ git checkout\n Your branch and 'gitweb-kernel.org/gitweb-ml-v5' have diverged,\n and have 912 and 9 different commit(s) each, respectively.\n\nP.P.S. When documentation is insufficient, you can always as last resort\ntake a look at git test suite, e.g. at t/t3000-ls-files* and \nt/t7508-status.sh\n-- \nJakub Narebski\nPoland\n"},{"id":"139054","messageId":"20100409162425.GA32575@thyrsus.com","threadId":"23387","inReplyTo":"vpqy6gw7lio.fsf@bauges.imag.fr","subject":"Re: Status of all files (was: Re: How can I tell if a file is ignored by git?","fromName":"Eric Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2010-04-09T16:24:25Z","receivedAt":"2010-04-09T16:24:25Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Matthieu Moy :\n> Eric Raymond writes:\n> \n> > (The ls-files -t codes need better documentation. If I get detailed enough\n> > answers, I will write some.)\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/126516\n> \n> In short, \"git ls-files -t\" was written long ago, never tested, and\n> probably mostly used by no one. It has a very strange behavior, it's\n> not just the doc. I'd advise against using it.\n\nIt sounds very much to me as though this feature should be scheduled\nfor deletion.\n \n> \"git status --porcelain\" is probably what you want:\n> \n> --porcelain\n> Give the output in a stable, easy-to-parse format for\n> scripts. Currently this is identical to --short output, but\n> is guaranteed not to change in the future, making it safe\n> for scripts.\n\nYes, this looks like what I would want, all right - if the status\ncodes were actually *comprehensible*! \n\nWe should tackle this right now, because VC is not the last front end\nthat will need to parse the format and at least I am willing to patch\nyour docs based on what I learn. Most of your other customers won't\ndo that.\n\nI'm going to start a separate thread about this.\n-- \n\t\tEric S. Raymond\n"},{"id":"139057","messageId":"7v8w8w36wa.fsf@alter.siamese.dyndns.org","threadId":"23387","inReplyTo":"vpqy6gw7lio.fsf@bauges.imag.fr","subject":"Re: Status of all files (was: Re: How can I tell if a file is ignored by git?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-09T16:52:37Z","receivedAt":"2010-04-09T16:52:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy writes:\n\n> In short, \"git ls-files -t\" was written long ago, never tested, and\n> probably mostly used by no one.\n\nIt was added primarily for Cogito, which is presumably dead by now.\n"},{"id":"139087","messageId":"t2w62a3a9cb1004091618i13fff1a7iad65e073e2292848@mail.gmail.com","threadId":"23387","inReplyTo":"z2h62a3a9cb1004091615q52bd5f5aqc24079de7f0038ba@mail.gmail.com","subject":"Re: Status of all files (was: Re: How can I tell if a file is ignored by git?","fromName":"Daniel Grace","fromEmail":"negativeview@gmail.com","sentAt":"2010-04-09T23:18:53Z","receivedAt":"2010-04-09T23:18:53Z","isPatch":false,"sender":{"key":"negativeview@gmail.com","avatar":"https://gravatar.com/avatar/3cdfd055fcddbe166daf37ce403bfce216b100e8fc783998f43938ff77c388dc?d=mp&s=160"},"body":"Eric,\n\nI am working on a similar program (not ready for announcing yet). I\nhave not gotten to the part that would need this, but I would be happy\nto start planning that stage and work with you to make sure that this\nfeature met both of our needs, and help write the documentation if\nneed be.\n\n(Sorry for the double everyone in To/Cc, gmail defaulted to HTML email\nand it was rejected from the list. I had to To/Cc you all again so\nthat Reply All from list members would work as expected.)\n\nDaniel\nhttp://www.doomstick.com\n\n\nOn Fri, Apr 9, 2010 at 6:15 PM, Daniel Grace wrote:\n>\n> Eric,\n> 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.\n> Daniel\n> http://www.doomstick.com\n>\n>\n> On Fri, Apr 9, 2010 at 11:24 AM, Eric Raymond wrote:\n>>\n>> Matthieu Moy :\n>> > Eric Raymond writes:\n>> >\n>> > > (The ls-files -t codes need better documentation. If I get detailed enough\n>> > > answers, I will write some.)\n>> >\n>> > http://thread.gmane.org/gmane.comp.version-control.git/126516\n>> >\n>> > In short, \"git ls-files -t\" was written long ago, never tested, and\n>> > probably mostly used by no one. It has a very strange behavior, it's\n>> > not just the doc. I'd advise against using it.\n>>\n>> It sounds very much to me as though this feature should be scheduled\n>> for deletion.\n>>\n>> > \"git status --porcelain\" is probably what you want:\n>> >\n>> > --porcelain\n>> > Give the output in a stable, easy-to-parse format for\n>> > scripts. Currently this is identical to --short output, but\n>> > is guaranteed not to change in the future, making it safe\n>> > for scripts.\n>>\n>> Yes, this looks like what I would want, all right - if the status\n>> codes were actually *comprehensible*!\n>>\n>> We should tackle this right now, because VC is not the last front end\n>> that will need to parse the format and at least I am willing to patch\n>> your docs based on what I learn. Most of your other customers won't\n>> do that.\n>>\n>> I'm going to start a separate thread about this.\n>> --\n>> Eric S. Raymond\n>> --\n>> To unsubscribe from this list: send the line \"unsubscribe git\" in\n>> the body of a message to majordomo@vger.kernel.org\n>> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"139101","messageId":"20100410033505.GB18634@thyrsus.com","threadId":"23387","inReplyTo":"z2h62a3a9cb1004091615q52bd5f5aqc24079de7f0038ba@mail.gmail.com","subject":"Re: Status of all files (was: Re: How can I tell if a file is ignored by git?","fromName":"Eric Raymond","fromEmail":"esr@thyrsus.com","sentAt":"2010-04-10T03:35:05Z","receivedAt":"2010-04-10T03:35:05Z","isPatch":false,"sender":{"key":"esr@thyrsus.com","avatar":"https://avatars.githubusercontent.com/u/727961?v=4"},"body":"Daniel Grace :\n> I am working on a similar program (not ready for announcing yet). I have not\n> gotten to the part that would need this, but I would be happy to start\n> planning that stage and work with you to make sure that this feature met\n> both of our needs, and help write the documentation if need be.\n\nI'm willing to cooperate.\n-- \n\t\tEric S. Raymond\n"},{"id":"139182","messageId":"7vsk73w2ho.fsf@alter.siamese.dyndns.org","threadId":"23387","inReplyTo":"864ojkx1un.fsf@red.stonehenge.com","subject":"Re: Status of all files (was: Re: How can I tell if a file is ignored by git?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-04-10T19:07:15Z","receivedAt":"2010-04-10T19:07:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n> A lot of these don't make sense for git and other DVCS.\n\nI agree with you in principle, but not with the details in the example.\n\n> For example:\n>\n> Eric> 'needs-update The file has not been edited by the user, but there is\n> Eric> a more recent version on the current branch stored\n> Eric> in the master file.\n>\n> This makes sense only with a file-based VCS, not a tree-based VCS like\n> git.\n\nThis isn't about file vs tree, but more about centralized vs distributed.\nIn DVCS workflows \"needs-update\" as a concept does not even exist when you\nare working on a topic branch to perfect one thing and one thing only.\nYou do not want to update only because somebody else did some work that\nmay be totally unrelated to what you wanted to achieve on the current\nbranch.\n\nI presume that many people use git in centralized workflow where they use\nonly 'master' branch and \"git pull ; work ; git commit; git push\" are the\nonly things they do. In that setting, \"needs-update\" may make sense. The\nVC backend implementation has to do \"git fetch\" to see if the origin has\nadvanced.\n\nAlmost the same comment applies to 'needs-merge', but the VC backend not\nonly needs to worry about \"file has been edited\", but also \"commits that\ntouch the file has been made locally\".\n\n> Eric> 'removed Scheduled to be deleted from the repository\n> Eric> on next commit.\n>\n> Not useful in git.\n\nIsn't \"git rm removed\" exactly \"scheduled to be deleted\"?\n\n> Eric> 'missing The file is not present in the file system, but the VC\n> Eric> system still tracks it.\n>\n> Not available in git. (If it's not a real file, it can't be tracked. :)\n\nIsn't \"rm missing\" exactly this?\n\n> Eric> 'ignored The file showed up in a dir-status listing with a flag\n> Eric> indicating the version-control system is ignoring it,\n>\n> Eric> 'unregistered The file is not under version control.\n>\n> These two would be identical in git.\n\nIgnored is a subset of Unregistered, no? Neither exists in the index\n(i.e. not tracked); ignored ones are covered by .gitignore and you need to\nforce \"git add\" to start tracking them.\n"},{"id":"139204","messageId":"4BC0F7D1.6000003@gnu.org","threadId":"23387","inReplyTo":"20100409140215.GB27899@thyrsus.com","subject":"Re: Status of all files","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2010-04-10T22:12:33Z","receivedAt":"2010-04-10T22:12:33Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"On 04/09/2010 04:02 PM, Eric Raymond wrote:\n>>> > >\n>>> > > 'needs-update The file has not been edited by the user, but there is\n>>> > > a more recent version on the current branch stored\n>>> > > in the master file.\n>> >\n>> > Needs*update* looks like it came from centralized VCS like CVS and\n>> > Subversion, where you use update-the-commit method. You can't say\n>> > that HEAD version is more recent that working file...\n>> >\n>> > The rought equivalent would be that upstream branch for current\n>> > branch (e.g. 'origin/master' can be upstream for 'master' branch) is\n>> > in fast-forward state i.e. current branch is direct ancestor of\n>> > corresponding upstream branch, and the file was modified upstream.\n>\n> Agreed. But there's no way to tell that this is the case without\n> doing a pull operation or otherwise querying origin, and I'm\n> not going to do that.\n\nYou can query the origin _as it was on the last fetch_.\n\nIf you are on branch X, the logic is as follows:\n\n- Let R be the value of configuration key branch.X.remote,\n- let M be the value of configuration key branch.X.merge,\n- for all values S of configuration key remote.R.fetch,\n - strip an initial +\n - if S is M:N, return N\n - if S is P/*:Q/* where P is a prefix of M, take M, replace this\n prefix with Q and return the result\n\nIn the most common case you will have:\n\n- X = master\n- R = origin\n- M = refs/heads/master\n- one key S = +refs/heads/*:refs/remotes/origin/*\n\nso the prefix \"refs/heads/\" is replaced with \"refs/remotes/origin/\" and \nthe result is refs/remotes/origin/master.\n\nPaolo\n"},{"id":"139240","messageId":"20100411102534.GC20484@coredump.intra.peff.net","threadId":"23387","inReplyTo":"4BC0F7D1.6000003@gnu.org","subject":"Re: Status of all files","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-04-11T10:25:35Z","receivedAt":"2010-04-11T10:25:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Apr 11, 2010 at 12:12:33AM +0200, Paolo Bonzini wrote:\n\n> >Agreed. But there's no way to tell that this is the case without\n> >doing a pull operation or otherwise querying origin, and I'm\n> >not going to do that.\n> \n> You can query the origin _as it was on the last fetch_.\n> \n> If you are on branch X, the logic is as follows:\n> \n> - Let R be the value of configuration key branch.X.remote,\n> - let M be the value of configuration key branch.X.merge,\n> - for all values S of configuration key remote.R.fetch,\n> - strip an initial +\n> - if S is M:N, return N\n> - if S is P/*:Q/* where P is a prefix of M, take M, replace this\n> prefix with Q and return the result\n> \n> In the most common case you will have:\n> \n> - X = master\n> - R = origin\n> - M = refs/heads/master\n> - one key S = +refs/heads/*:refs/remotes/origin/*\n> \n> so the prefix \"refs/heads/\" is replaced with \"refs/remotes/origin/\"\n> and the result is refs/remotes/origin/master.\n\nBTW, this procedure is complex enough that we have exposed it via a\nplumbing interface:\n\n $ git for-each-ref --format='%(upstream)' refs/heads/master\n refs/remotes/origin/master\n\nwhich does all of the correct magic internally.\n\n-Peff\n"}]}