{"thread":{"id":"591","subject":"[PATCH] Ignore file filter","startedAt":"2005-05-12T21:30:32Z","lastAt":"2005-05-16T16:05:01Z","messageCount":18,"participants":["David Greaves","Petr Baudis","Junio C Hamano","Jon Seymour","Matthias Urlichs"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"3203","messageId":"4283CAF8.3050304@dgreaves.com","threadId":"591","inReplyTo":null,"subject":"[PATCH] Ignore file filter","fromName":"David Greaves","fromEmail":"david@dgreaves.com","sentAt":"2005-05-12T21:30:32Z","receivedAt":"2005-05-12T21:30:32Z","isPatch":true,"sender":{"key":"david@dgreaves.com","avatar":"https://gravatar.com/avatar/ca67bad50999edcdd137c9a65da2381557d175bea99ae956afdabc5785e42b79?d=mp&s=160"},"body":"Hi Petr\n\nThis is an inline filter that introduces the concept of .git/ignore\nIt is intended to be used within the cogito scripts like the other cg-X*\nfiles.\n\n\nSigned-off-by: David Greaves <david@dgreaves.com>\n\n-- \n\n\n\n#!/usr/bin/env bash\n#\n# Takes a list of files on stdin and only passes valid ones agording to .git/ignore\n# Copyright (c) David Greaves, 2005\n#\n# This filter implements cogito ignore rules and should typically be used in find pipelines\n#\n# Synopsis\n# cg-Xignore [-debug] [-f] [-h] [-d] < file-list >useful-file-list\n#\n# Options\n# -debug::\n#     produce helpful debug output\n#\n# -q::\n#     don't say what paths are ignored\n#\n# -f::\n#     passes files\n#\n# -d::\n#     passes directories\n#\n# -h::\n#     passes symbolic links\n#\n# The default is to pass all file types that are not ignored.\n#\n# Note that the .git/ignore file contains multiple expressions, 1 per line\n# Lines beginning with a '#' are ignored (allowing comments)\n# These are 'bash regular expressions' not glob patterns\n# This allows ignore rules to take the directory into account\n# Suggested contents:\n#   # bash regexps (not globs)\n#   ^\\.[^/]\n#   /\\.\n#   /$\n#   .*\\.o$\n\n\n# This doesn't allow the -h which is the [ arg for symlinks...\n#. ${COGITO_LIB}cg-Xlib\n_git=${GIT_DIR:-.git}\n\nIGNORE_FILE=\"$_git/ignore\"\n\nif [ \"$1\" = \"-0\" ]; then\n    # doesn't work :(\n    zerosep=$'-d \"\\0\"'\n    shift\nfi\n\n# Defaults\npass_files=0\npass_dirs=0\npass_links=0\npass_all=1\nwhile [ $# -gt 0 ]; do\n    case $1 in\n\t\"-f\")\n\t    pass_all=0\n\t    pass_files=1\n\t    ;;\n\t\"-d\")\n\t    pass_all=0\n\t    pass_dirs=1\n\t    ;;\n\t\"-h\")\n\t    pass_all=0\n\t    pass_links=1\n\t    ;;\n\t\"-q\")\n\t    quiet=1\n\t    ;;\n\t\"-debug\")\n\t    debug=1\n\t    ;;\n\tesac\n    shift\ndone\n\n# save stderr\nexec 5>&2\nif [ $quiet ]; then\n    # turn off noise\n    exec 2>&-\nfi\n\nif [ $debug ]; then\n    exec 4>&5\nelse\n    exec 4>/dev/null\nfi\n\n\n# Strip out the common leading ./ allowing \"find .\"\nsed 's:^./::' | \\\nwhile read $zerosep file; do\n    echo \"consider file: $file\" >&4\n    ignore=0\n    if [ -f $IGNORE_FILE ]; then\n\texec 3<$IGNORE_FILE\n\twhile read -r -u3 patt ; do\n\t    if [[ $patt =~ \"^\\w*#\" ]]; then\n\t\tcontinue\n\t    fi\n\t    echo \"consider pattern: $patt\" >&4\n\t    if [[ $file =~ $patt ]]; then\n\t\tignore=1\n\t\techo \"Ignoring $file because of $patt\" >&2\n\t\tbreak\n\t    fi\n\tdone\n    fi\n    echo \"passing file: $file\" >&4\n    \n    if [ $ignore != \"1\" \\\n\t-a \\( $pass_all -eq 1 \\\n\t   -o \\( $pass_files -eq 1 -a -f $file \\) \\\n\t   -o \\( $pass_dirs  -eq 1 -a -d $file \\) \\\n\t   -o \\( $pass_links -eq 1 -a -h $file \\) \\\n\t   \\) \\\n\t]; then\n\techo $file\n    fi\ndone\n"},{"id":"3238","messageId":"42846A3F.4030706@dgreaves.com","threadId":"591","inReplyTo":"7v64xodshs.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Ignore file filter","fromName":"David Greaves","fromEmail":"david@dgreaves.com","sentAt":"2005-05-13T08:50:07Z","receivedAt":"2005-05-13T08:50:07Z","isPatch":true,"sender":{"key":"david@dgreaves.com","avatar":"https://gravatar.com/avatar/ca67bad50999edcdd137c9a65da2381557d175bea99ae956afdabc5785e42b79?d=mp&s=160"},"body":"Junio C Hamano wrote:\n\n>Just a half theoretical question.  How well does this perform\n>when your filenames have:\n>\n>    - ' '  (ASCII 0x20)\n>    - '\\t' (ASCII 0x09)\n>    - '\\n' (ASCII 0x0a)\n>    - '`'  (ASCII 0x60) backtick\n>    - '$'  (ASCII 0x24) dollar sign\n>\n>in them?  Or is it the case that the rest of the Cogito is not\n>careful enough and it does not matter to be careful only in this\n>script?\n>  \n>\nThat's what the:\nzerosep=$'-d \"\\0\"'\nis for.\nIt looks like the shell 'read' doesn't honour it though - I couldn't\nmake it work.\n\nHowever, thanks, after I fixed the quotes I missed in:\n-o \\( $pass_files -eq 1 -a -f \"$file\" \\) \\\n-o \\( $pass_dirs -eq 1 -a -d \"$file\" \\) \\\n-o \\( $pass_links -eq 1 -a -h \"$file\" \\) \\\n\nit handles all cases above except \\n (of course)\n\nFrankly I think we're beyond shell programming and we should be using\nperl (IMHO as the 'best' and most portable text handler)\nIt also has a *fantastic* test harness available.\n\nDavid\n"},{"id":"3265","messageId":"20050513231229.GI32232@pasky.ji.cz","threadId":"591","inReplyTo":"4283CAF8.3050304@dgreaves.com","subject":"Re: [PATCH] Ignore file filter","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-05-13T23:12:29Z","receivedAt":"2005-05-13T23:12:29Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, May 12, 2005 at 11:30:32PM CEST, I got a letter\nwhere David Greaves <david@dgreaves.com> told me that...\n> # This doesn't allow the -h which is the [ arg for symlinks...\n\nBut so is -L. And I'd just use -l...\n\n> #. ${COGITO_LIB}cg-Xlib\n> _git=${GIT_DIR:-.git}\n\n...but it makes no sense anyway I think to reinclude this stuff from a\ncg-Xfile you are including from other scripts anyway.\n\n> \t    if [[ $file =~ $patt ]]; then\n\nI'm sorry but this is really nothing my bash-2.05.0(1)-release supports.\nWe're already bash-only, but further reducing that to bash3 really won't\nwork. I *might* get convinced to add some bash2+-only feature, but only\nif you'll be really good at explaining that it makes sense.\n\nBesides, I'd prefer just the shell globs in the ignore file, as it is\ndone in the rest of the world, and in all the real-world scenarios I've\nseen, the globs were powerful enough.\n\nAlso, how does this interact with git-ls-files --exclude and\n.git/exclude? We would have two ignoring mechanisms...\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"3291","messageId":"4285B6A8.4080309@dgreaves.com","threadId":"591","inReplyTo":"20050513231229.GI32232@pasky.ji.cz","subject":"Re: [PATCH] Ignore file filter","fromName":"David Greaves","fromEmail":"david@dgreaves.com","sentAt":"2005-05-14T08:28:24Z","receivedAt":"2005-05-14T08:28:24Z","isPatch":true,"sender":{"key":"david@dgreaves.com","avatar":"https://gravatar.com/avatar/ca67bad50999edcdd137c9a65da2381557d175bea99ae956afdabc5785e42b79?d=mp&s=160"},"body":"Petr Baudis wrote:\n\n>Dear diary, on Thu, May 12, 2005 at 11:30:32PM CEST, I got a letter\n>where David Greaves <david@dgreaves.com> told me that...\n>  \n>\n>># This doesn't allow the -h which is the [ arg for symlinks...\n>>    \n>>\n>\n>But so is -L. And I'd just use -l...\n>  \n>\nOK\n\n>>#. ${COGITO_LIB}cg-Xlib\n>>_git=${GIT_DIR:-.git}\n>>    \n>>\n>\n>...but it makes no sense anyway I think to reinclude this stuff from a\n>cg-Xfile you are including from other scripts anyway.\n>  \n>\ncg-Xignore isn't included - only called.\nit's also just a library program.\nAlso I don't think cg-Xlib should be doing arg handling.\nAs an include it should provide an arg handling function that the\nscripts call.\n\n>>\t    if [[ $file =~ $patt ]]; then\n>>    \n>>\n>\n>I'm sorry but this is really nothing my bash-2.05.0(1)-release supports.\n>We're already bash-only, but further reducing that to bash3 really won't\n>work. I *might* get convinced to add some bash2+-only feature, but only\n>if you'll be really good at explaining that it makes sense.\n>  \n>\nAh\nOK\nI don't know how to do that.\nI was actually aiming for glob matching when I came upon this in the\nmanpage.\nI just thought it was bash and didn't think to check what version it was\nintroduced with.\n\n>Besides, I'd prefer just the shell globs in the ignore file, as it is\n>done in the rest of the world, and in all the real-world scenarios I've\n>seen, the globs were powerful enough.\n>\n>Also, how does this interact with git-ls-files --exclude and\n>.git/exclude? We would have two ignoring mechanisms...\n>\n>  \n>\nbecause one was cogito's and one was git's.\nCogitos was supposed to have a more powerful, pattern based abroach.\n\nDavid\n\n-- \n\n"},{"id":"3294","messageId":"7vy8ai2nb6.fsf@assigned-by-dhcp.cox.net","threadId":"591","inReplyTo":"4285B6A8.4080309@dgreaves.com","subject":"Re: [PATCH] Ignore file filter","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-14T09:01:49Z","receivedAt":"2005-05-14T09:01:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"DG\" == David Greaves <david@dgreaves.com> writes:\n\n>>> if [[ $file =~ $patt ]]; then\n>> \n>> I'm sorry but this is really nothing my bash-2.05.0(1)-release supports.\nDG> OK\nDG> I don't know how to do that.\n\nIs that regexp or shell glob?  If regexp, expr is your friend,\nlike this:\n\n    if expr \"$file\" : \"$patt\" >/dev/null; then\n\nFor a glob:\n\n    patt='?.sh'\n    file=1.sh\n\n    case \"$file\" in\n    $patt)\n            echo Yeah ;;\n    *)\n            echo No ;;\n    esac\n\n"},{"id":"3305","messageId":"20050514122134.GF3905@pasky.ji.cz","threadId":"591","inReplyTo":"4285B6A8.4080309@dgreaves.com","subject":"Re: [PATCH] Ignore file filter","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-05-14T12:21:34Z","receivedAt":"2005-05-14T12:21:34Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, May 14, 2005 at 10:28:24AM CEST, I got a letter\nwhere David Greaves <david@dgreaves.com> told me that...\n> >>#. ${COGITO_LIB}cg-Xlib\n> >>_git=${GIT_DIR:-.git}\n> >>    \n> >>\n> >\n> >...but it makes no sense anyway I think to reinclude this stuff from a\n> >cg-Xfile you are including from other scripts anyway.\n> >  \n> >\n> cg-Xignore isn't included - only called.\n\nOh yes, I'm stupid.\n\n> it's also just a library program.\n> Also I don't think cg-Xlib should be doing arg handling.\n> As an include it should provide an arg handling function that the\n> scripts call.\n\nI'd prefer the few and scattered users which don't want arg handling to\nexplicitly set some magic variable before calling cg-Xlib rather than\nadding the arg parser function call everywhere else.\n\n> >>\t    if [[ $file =~ $patt ]]; then\n> >>    \n> >>\n> >\n> >I'm sorry but this is really nothing my bash-2.05.0(1)-release supports.\n> >We're already bash-only, but further reducing that to bash3 really won't\n> >work. I *might* get convinced to add some bash2+-only feature, but only\n> >if you'll be really good at explaining that it makes sense.\n> >  \n> >\n> Ah\n> OK\n> I don't know how to do that.\n> I was actually aiming for glob matching when I came upon this in the\n> manpage.\n\nOk, so what's the outcome? Are you going to stop at this point, or will\nyou change the scripts so that they use the glob list?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"3306","messageId":"20050514142421.GG3905@pasky.ji.cz","threadId":"591","inReplyTo":"7vy8ai2nb6.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Ignore file filter","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-05-14T14:24:22Z","receivedAt":"2005-05-14T14:24:22Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, May 14, 2005 at 11:01:49AM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> >>>>> \"DG\" == David Greaves <david@dgreaves.com> writes:\n> \n> >>> if [[ $file =~ $patt ]]; then\n> >> \n> >> I'm sorry but this is really nothing my bash-2.05.0(1)-release supports.\n> DG> OK\n> DG> I don't know how to do that.\n> \n> Is that regexp or shell glob?  If regexp, expr is your friend,\n> like this:\n> \n>     if expr \"$file\" : \"$patt\" >/dev/null; then\n\nOh, this looks nice. I didn't know expr can do that. :-)\n\nStill, I'd prefer the old-fashioned globs as primary matching mechanism.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"3308","messageId":"42860AF7.3060208@dgreaves.com","threadId":"591","inReplyTo":"20050514122134.GF3905@pasky.ji.cz","subject":"Re: [PATCH] Ignore file filter","fromName":"David Greaves","fromEmail":"david@dgreaves.com","sentAt":"2005-05-14T14:28:07Z","receivedAt":"2005-05-14T14:28:07Z","isPatch":true,"sender":{"key":"david@dgreaves.com","avatar":"https://gravatar.com/avatar/ca67bad50999edcdd137c9a65da2381557d175bea99ae956afdabc5785e42b79?d=mp&s=160"},"body":"Petr Baudis wrote:\n\n>Dear diary, on Sat, May 14, 2005 at 10:28:24AM CEST, I got a letter\n>where David Greaves <david@dgreaves.com> told me that...\n>  \n>\n>>Also I don't think cg-Xlib should be doing arg handling.\n>>As an include it should provide an arg handling function that the\n>>scripts call.\n>>    \n>>\n>\n>I'd prefer the few and scattered users which don't want arg handling to\n>explicitly set some magic variable before calling cg-Xlib rather than\n>adding the arg parser function call everywhere else.\n>  \n>\nOK\n\n>>>>\t    if [[ $file =~ $patt ]]; then\n>>>>        \n>>>>\n>>>I'm sorry but this is really nothing my bash-2.05.0(1)-release supports.\n>>>We're already bash-only, but further reducing that to bash3 really won't\n>>>work. I *might* get convinced to add some bash2+-only feature, but only\n>>>if you'll be really good at explaining that it makes sense.\n>>>      \n>>>\n>>OK\n>>I don't know how to do that.\n>>I was actually aiming for glob matching when I came upon this in the\n>>manpage.\n>>    \n>>\n>Ok, so what's the outcome? Are you going to stop at this point, or will\n>you change the scripts so that they use the glob list?\n>  \n>\nWell, Junio solved that for me - I'll gather the comments and resubmit.\n\nDavid\n\n-- \n\n"},{"id":"3315","messageId":"42861584.6020601@dgreaves.com","threadId":"591","inReplyTo":"20050514142421.GG3905@pasky.ji.cz","subject":"Re: [PATCH] Ignore file filter","fromName":"David Greaves","fromEmail":"david@dgreaves.com","sentAt":"2005-05-14T15:13:08Z","receivedAt":"2005-05-14T15:13:08Z","isPatch":true,"sender":{"key":"david@dgreaves.com","avatar":"https://gravatar.com/avatar/ca67bad50999edcdd137c9a65da2381557d175bea99ae956afdabc5785e42b79?d=mp&s=160"},"body":"Petr Baudis wrote:\n\n>Dear diary, on Sat, May 14, 2005 at 11:01:49AM CEST, I got a letter\n>where Junio C Hamano <junkio@cox.net> told me that...\n>  \n>\n>>>>>>>\"DG\" == David Greaves <david@dgreaves.com> writes:\n>>>>>>>              \n>>>>>>>\n>>>>>if [[ $file =~ $patt ]]; then\n>>>>>          \n>>>>>\n>>>>I'm sorry but this is really nothing my bash-2.05.0(1)-release supports.\n>>>>        \n>>>>\n>>DG> OK\n>>DG> I don't know how to do that.\n>>\n>>Is that regexp or shell glob?  If regexp, expr is your friend,\n>>like this:\n>>\n>>    if expr \"$file\" : \"$patt\" >/dev/null; then\n>>    \n>>\n>\n>Oh, this looks nice. I didn't know expr can do that. :-)\n>\n>Still, I'd prefer the old-fashioned globs as primary matching mechanism.\n>  \n>\nOK\nI was wondering about supporting _both_ globs and re's\nright now my ignore file has a # to precede comment lines\nmaybe re: precedes regexp lines and unadorned lines are globs.\n\nHowever the re's provided by regex(7) are too weedy to be worth\nbothering with.\nIf however, there is a serious plan to go to perl, it may be worth\nproviding for this now in the ignore syntax.\n\nAdditionally this causes problems with sharing the same exclude file as\nused by git.\nHowever...\nI really think git's exclude file capability and cogito's are different.\nCogito is aiming to provide full-blown SCM capabilities - git isn't\n\nI am also concerned that a centralised ignore file is not flexible enough.\nCertainly limiting if we support globs only.\nIt may be that you want different rules in different trees - someone on\nlkml mentioned that excludes vary in different parts of the source.\nEg .s files may be generally ignored - but not in the asm parts of the tree.\n\nAlso... you haven't mentioned perl for a while - can you give us an update?\nI personally think we're making life needlessly unpleasant by sticking\nwith shell.\n\n\nDavid\n\n-- \n\n"},{"id":"3319","messageId":"20050514153027.GN3905@pasky.ji.cz","threadId":"591","inReplyTo":"42861584.6020601@dgreaves.com","subject":"[RFD] Ignore rules","fromName":"Petr Baudis","fromEmail":"pasky@ucw.cz","sentAt":"2005-05-14T15:30:27Z","receivedAt":"2005-05-14T15:30:27Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Here, I would like more people to speak up, plaese, especially the\nauthors of other layers over git than Cogito, since I think it'd be\ngreat if we could agree on common ignore rules format and we could just\ncall the files \".gitignore\" instead of \".cgignore\", \".jitignore\" etc.\n\n\nDear diary, on Sat, May 14, 2005 at 05:13:08PM CEST, I got a letter\nwhere David Greaves <david@dgreaves.com> told me that...\n> I was wondering about supporting _both_ globs and re's\n> right now my ignore file has a # to precede comment lines\n\nI assume \\# will override that?\n\n> maybe re: precedes regexp lines and unadorned lines are globs.\n\nOr maybe even /, which is the common regexp prefix anyway...\n\nTo mention it in this mail too, I think leading '!' should do the\n\"ignore exclude\" - that is, it would override any possible previous\nignore decisions about the file. E.g. '!*' would throw away all\npreviously applied ignore rules.\n\n> However the re's provided by regex(7) are too weedy to be worth\n> bothering with.\n> If however, there is a serious plan to go to perl, it may be worth\n> providing for this now in the ignore syntax.\n> \n> Also... you haven't mentioned perl for a while - can you give us an update?\n> I personally think we're making life needlessly unpleasant by sticking\n> with shell.\n\nIf there is still a serious plan, it is much more long-term now, since\nshell turns out to keep doing fine and everything we need, and that all\nreasonably fast.\n\nThat said, I think it's fine to use Perl regexps. I think they rule. :-)\nBut what do others think? Should we stick with POSIX regexps (I assume\nat least extended instead of basic), or go with Perl regexps?\n\n> Additionally this causes problems with sharing the same exclude file as\n> used by git.\n> However...\n> I really think git's exclude file capability and cogito's are different.\n> Cogito is aiming to provide full-blown SCM capabilities - git isn't\n\nIf we get to agree on some common format, I'm thinking whether it\nwouldn't be actually good to extend the --exclude option to support it.\nHow much of an issue would that be? What do others think?\n\n> I am also concerned that a centralised ignore file is not flexible enough.\n> Certainly limiting if we support globs only.\n> It may be that you want different rules in different trees - someone on\n> lkml mentioned that excludes vary in different parts of the source.\n> Eg .s files may be generally ignored - but not in the asm parts of the tree.\n\nI imagine it as (ignore rules applied in this order):\n\n<default ignore list>:\n\nSome builtin ignore list catching files like *.o, *.a and such.\nRemember that you can throw it away with !* if you don't like it.\n\n/.git/ignore:\n\nPer-repository ignore list, not version tracked etc; really a local thing.\n\n/.gitignore\n/**/.gitignore:\n\n(Applied in the order from the project root to the current directory.)\nVersion tracked ignore list, which concerns the current directory, BUT\nmay match pathnames instead of just filenames (but no ..). That is, you\ncould do something like\n\n\techo '*.o' >.gitignore\n\nto ignore all the object files in the current directory, and\n\n\techo '**.o' >.gitignore\n\nto also ignore the object files in all the subdirectories.\n\n\nOpinions?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nC++: an octopus made by nailing extra legs onto a dog. -- Steve Taylor\n"},{"id":"3332","messageId":"42863AAF.7020506@dgreaves.com","threadId":"591","inReplyTo":"20050514153027.GN3905@pasky.ji.cz","subject":"Re: [RFD] Ignore rules","fromName":"David Greaves","fromEmail":"david@dgreaves.com","sentAt":"2005-05-14T17:51:43Z","receivedAt":"2005-05-14T17:51:43Z","isPatch":false,"sender":{"key":"david@dgreaves.com","avatar":"https://gravatar.com/avatar/ca67bad50999edcdd137c9a65da2381557d175bea99ae956afdabc5785e42b79?d=mp&s=160"},"body":"Petr Baudis wrote:\n\n>Here, I would like more people to speak up, plaese, especially the\n>authors of other layers over git than Cogito, since I think it'd be\n>great if we could agree on common ignore rules format and we could just\n>call the files \".gitignore\" instead of \".cgignore\", \".jitignore\" etc.\n>\n>\n>Dear diary, on Sat, May 14, 2005 at 05:13:08PM CEST, I got a letter\n>where David Greaves <david@dgreaves.com> told me that...\n>  \n>\n>>I was wondering about supporting _both_ globs and re's\n>>right now my ignore file has a # to precede comment lines\n>>    \n>>\n>\n>I assume \\# will override that?\n>  \n>\ndoesn't match /^\\w#/ so yes\n\n>>maybe re: precedes regexp lines and unadorned lines are globs.\n>>    \n>>\n>Or maybe even /, which is the common regexp prefix anyway...\n>  \n>\nI thought about it but thought it would look strange since we won't want\na closing /\nOTOH, no globs will start with a / since they have to be relative so\nmaybe a good choice after all.\n\n>To mention it in this mail too, I think leading '!' should do the\n>\"ignore exclude\" - that is, it would override any possible previous\n>ignore decisions about the file. E.g. '!*' would throw away all\n>previously applied ignore rules.\n>  \n>\nWell, CVS has a lone ! meaning just that.\nI wonder if we should simply say that most patterns are 'ignore' patterns.\n'!' patterns are 'accept' patterns.\nThe last seen pattern wins\n\nso given:\n*.o\n!fre*.o\nfreddy.o\n\nfrog.o is ignored\nfred.o is seen\nfreddy.o is ignored\n\nThis means !* (or is that !**) has the same effect as a lone ! in CVS.\n\n>>However the re's provided by regex(7) are too weedy to be worth\n>>bothering with.\n>>If however, there is a serious plan to go to perl, it may be worth\n>>providing for this now in the ignore syntax.\n>>\n>>Also... you haven't mentioned perl for a while - can you give us an update?\n>>I personally think we're making life needlessly unpleasant by sticking\n>>with shell.\n>>    \n>>\n>\n>If there is still a serious plan, it is much more long-term now, since\n>shell turns out to keep doing fine and everything we need, and that all\n>reasonably fast.\n>\n>That said, I think it's fine to use Perl regexps. I think they rule. :-)\n>But what do others think? Should we stick with POSIX regexps (I assume\n>at least extended instead of basic), or go with Perl regexps?\n>  \n>\nI vote perl re's\nYou have the power if needed but most of the time it'll be basic regexps.\nI think if we have a central 'path' matching .git/ignore then regexps\nare needed.\nThen if we have them, we may as well allow them.\nOTOH: A plethora of .gitignore files with the !negation mechanism may\nmake globs adequate.\n\n>>Additionally this causes problems with sharing the same exclude file as\n>>used by git.\n>>However...\n>>I really think git's exclude file capability and cogito's are different.\n>>Cogito is aiming to provide full-blown SCM capabilities - git isn't\n>>    \n>>\n>\n>If we get to agree on some common format, I'm thinking whether it\n>wouldn't be actually good to extend the --exclude option to support it.\n>How much of an issue would that be? What do others think?\n>  \n>\nI'm not convinced it needs to be extended.\nIt's trivial to take git-ls-files and filter it's results.\nThe rest of git will need filtering.\n\n>>I am also concerned that a centralised ignore file is not flexible enough.\n>>Certainly limiting if we support globs only.\n>>It may be that you want different rules in different trees - someone on\n>>lkml mentioned that excludes vary in different parts of the source.\n>>Eg .s files may be generally ignored - but not in the asm parts of the tree.\n>>    \n>>\n>\n>I imagine it as (ignore rules applied in this order):\n>\n><default ignore list>:\n>\n>Some builtin ignore list catching files like *.o, *.a and such.\n>  \n>\nWhy builtin?\nWhy not have a default setup for .git/ignore\nThe way I'd do it is in cg-init :\n[ -f cogito.ignore ] && mv cogito.ignore .git/ignore\n[ ! -f .git/ignore ] && cat <<STD_IGNORE > .git/ignore\n\n>Remember that you can throw it away with !* if you don't like it.\n>  \n>\nbut it means reading the man pages to find it out whilst you're editing\n.git/gitignore\nI could never remember what CVS ignored...\n\n>/.git/ignore:\n>\n>Per-repository ignore list, not version tracked etc; really a local thing.\n>  \n>\n~/.gitignore ?? CVS has it - personal prefs for your editor's strange\nnumbered backups etc\n\n>/.gitignore\n>/**/.gitignore:\n>\n>(Applied in the order from the project root to the current directory.)\n>  \n>\n>Version tracked ignore list, which concerns the current directory, BUT\n>may match pathnames instead of just filenames (but no ..). That is, you\n>could do something like\n>\n>\techo '*.o' >.gitignore\n>\n>to ignore all the object files in the current directory, and\n>\n>\techo '**.o' >.gitignore\n>\n>to also ignore the object files in all the subdirectories.\n>  \n>\nwell, is the matching against files or paths?\nAnd do .gitignores affect their sub-tree or just their dir?\nAnd if they're vc'ed then git needs to stop ignoring .files\n\n>\n>Opinions?\n>  \n>\n\nI think the global ignores contain both:\n* regexps against the path relative to the project root\n* regexps against the filename\n* shell globs against the filename\nI think the .gitignore's operate on a per-tree basis (so their directory\nand lower)\nI think .gitignore matching should be against filenames (not paths)\n\n# comments\n/regexp\n!/inverted regexp\nshellglob\n!inverted shellglob\n\n\n\n\nLesson from the CVS manual:\nSpecifying `-I !' to `cvs import' will import everything, which is\ngenerally what you want to do if you are importing files from a\npristine distribution or any other source which is known to not contain\nany extraneous files. However, looking at the rules above you will see\nthere is a fly in the ointment; if the distribution contains any\n`.cvsignore' files, then the patterns from those files will be\nprocessed even if `-I !' is specified. The only workaround is to\nremove the `.cvsignore' files in order to do the import. Because this\nis awkward, in the future `-I !' might be modified to override\n`.cvsignore' files in each directory.\n\n\n\n\n\n-- \n\n"},{"id":"3333","messageId":"7vsm0py8vz.fsf@assigned-by-dhcp.cox.net","threadId":"591","inReplyTo":"20050514153027.GN3905@pasky.ji.cz","subject":"Re: [RFD] Ignore rules","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-14T18:12:16Z","receivedAt":"2005-05-14T18:12:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"PB\" == Petr Baudis <pasky@ucw.cz> writes:\n\nPB> Here, I would like more people to speak up, plaese, especially the\nPB> authors of other layers over git than Cogito, since I think it'd be\nPB> great if we could agree on common ignore rules format and we could just\nPB> call the files \".gitignore\" instead of \".cgignore\", \".jitignore\" etc.\n\nPurely off the top of my head, without even regurgitating what\nyou wrote in the message I am responding to (sorry, I am about\nto leave for the day).\n\n * Two lists, one propagated with merges and another repository\n   private one.\n\n * GIT_DIR/info/ignore is the one propagated with merge but it\n   is not a list itself.  It records the name of a file that is\n   GIT tracked.  GIT_DIR/ignore is the repository private one.\n\n * Repository private one and then merge propagated one are read\n   in order, one line at a time.  The first hit determines\n   whether it is taken or ignored.\n\n * Each entry in the list is not a shell glob but a regexp.  The\n   ignore list rarely changes, so more expressiveness with a bit\n   higher learning curve and a bit more typing would not hurt\n   much.  The entry is implicitly anchored at the left and\n   matched against the path relative to what is recorded in\n   GIT_INDEX_FILE (so 'Makefile' matches \"Makefile\" in\n   linux-2.6.git/ but not \"fs/Makefile\").  The regexp can\n   optionally prefixed with a '!' to mean negation.  A line that\n   starts with a '#' is a comment.\n\n"},{"id":"3336","messageId":"2cfc4032050514181127c02e43@mail.gmail.com","threadId":"591","inReplyTo":"7vsm0py8vz.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFD] Ignore rules","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2005-05-15T01:11:08Z","receivedAt":"2005-05-15T01:11:08Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"Is there value in:\n\na. pushing the ignore logic into the core git tools such as git-ls-files\n\nb. including the current ignore .* rule as a default ignore rule that\ncan be overridden by a .gitignore file\n\n\njon.\n-- \nhomepage: http://www.zeta.org.au/~jon/\nblog: http://orwelliantremors.blogspot.com/\n"},{"id":"3342","messageId":"7v4qd5vxao.fsf@assigned-by-dhcp.cox.net","threadId":"591","inReplyTo":"2cfc4032050514181127c02e43@mail.gmail.com","subject":"Re: [RFD] Ignore rules","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-15T06:05:35Z","receivedAt":"2005-05-15T06:05:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"JS\" == Jon Seymour <jon.seymour@gmail.com> writes:\n\nJS> Is there value in:\n\nJS> a. pushing the ignore logic into the core git tools such as git-ls-files\n\nWhen there is an agreed upon Porcelain layer ignore logic,\ngit-ls-files --others --exclude-from=... should be changed so\nthat it uses the same file format and same semantics, and\nprobably use the default ignore file without being explicitly\ntold.  Otherwise things would get quite confusing, so yes, I see\nvalue in there.\n\nI do not however think this should apply to things like\n\"git-update-cache --add\"; because even though user may say\n\"git-update-cache --add *\" and wish it to ignore things on the\nignore list, that is not how shell parameter expansion works.\n\nI would like to see a git-path-helper command that can act as\nfilter between \"find -print0\" and \"xargs -0\" like this:\n\n    find * -print0 |\n    git-path-helper -z --ignore-file=.git/info/ignore |\n    xargs -r -0 git-update-cache --add --\n\nI envision that we should not even need --ignore-file parameter,\nonce we have \"an agreed upon Porcelain layer ignore logic\".  It\nshould read the \"agreed upon\" location, somewhere under the\n$GIT_DIR and perform the \"agreed upon\" filtering logic.\n\nI further envision that this would work from anywhere in the\nwork tree, not only from the directory that corresponds to the\ntop of the tree structure GIT_INDEX_FILE describes.  For\nexample, in linux-2.6 git tree, you _ought_ to be able to say\nsomething like this:\n\n    cd fs\n    find ext? ../include/linux -type f -print0 |\n    git-path-helper -z |\n    xargs -r -0 git-update-cache --add --\n\nThe git-path-helper command could internally run getpwd() and\nfind out the top directory (in this case, the parent directory\nof our current working directory \"fs\"), then canonicalize the\nincoming filenames (either relative to getpwd() or the full\nfilesystem path) to paths relative to the top directory, apply\nthe ignore filter and send the surviving paths downstream.\nAnything downstream driven with xargs -0 would get relative\npaths suitable for core GIT consumption.\n\nJS> b. including the current ignore .* rule as a default ignore rule that\nJS> can be overridden by a .gitignore file\n\nKnowing the number of places that assume .* are irrelevant, I\nwould not be looking forward to doing that myself, but that\nbehaviour would be ideal.\n\n\n"},{"id":"3346","messageId":"7vll6hugkp.fsf@assigned-by-dhcp.cox.net","threadId":"591","inReplyTo":"7v4qd5vxao.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFD] Ignore rules","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-15T06:52:06Z","receivedAt":"2005-05-15T06:52:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">>>>> \"JCH\" == Junio C Hamano <junkio@cox.net> writes:\n\nJCH> ...  For example, in linux-2.6 git tree, you _ought_ to be\nJCH> able to say something like this:\n\nJCH>     cd fs\nJCH>     find ext? ../include/linux -type f -print0 |\nJCH>     git-path-helper -z |\nJCH>     xargs -r -0 git-update-cache --add --\n\nThe above example has an obvious thinko/typo.  It should have\nbeen like this:\n\n     cd fs\n     find ext? ../include/linux -type f -print0 |\n     git-path-helper -z | {\n         cd .. && xargs -r -0 git-update-cache --add --\n     }\n\n"},{"id":"3384","messageId":"7vu0l4s08s.fsf_-_@assigned-by-dhcp.cox.net","threadId":"591","inReplyTo":"7v4qd5vxao.fsf@assigned-by-dhcp.cox.net","subject":"[RFD] git-run-with-user-path","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-05-15T20:27:47Z","receivedAt":"2005-05-15T20:27:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr, I have not written the implementation yet, but do you\nthink Cogito would find something like this useful?  I've seen\nsome patch to add running from subdirectory support to cg-add in\nthe mailing list and I assume Cogito is in the process of being\nenhanced in this area.\n\nJIT has been supporting running from the subdirectory from the\nday one, but has been using a bit different mechanism.  If we\ncan agree on a core-ish helper (I consider this just as non-core\nas git-diff-helper is), I would want to switch to use something\nlike this one.\n\nThis _deliberately_ conflates the user-path canonicalization\nwith the ignore-list processing discussed recently on the list.\nWhen you think about it, they are very closely related and\nhandling them at the same place makes more sense than having\nthem separately.  It is a way to munge paths given by users and\n\"find -print0 | xargs -0\" into a form appropriate for core GIT\nconsumption. Similar reasoning with which you accepted the use\nof cg-Xignore by David Greaves in cg-commit.\n\nLinus, and everybody else, suggestions and comments?\n\n------------\n\ngit-run-with-user-path(1)\n=========================\nv0.1, May 2005\n\nNAME\n----\ngit-run-with-user-path - Run command from the top after canonicalizing paths.\n\n\nSYNOPSIS\n--------\n'git-run-with-user-path' [options] <command> <argument>... '--' <path>...\n\nDESCRIPTION\n-----------\nThis command takes a <command>, zero or more <argument> and zero\nor more <path> arguments.  <path> arguments name objects on the\nfilesystem, <command> is typically a core GIT command, and\n<argument> are the initial arguments to the <command>.\n\nIt first finds the project top directory (the directory that\ncorresponds to the top of the tree structure GIT_INDEX_FILE\ndescribes), and canonicalizes the given <path> to be relative to\nthe project top.  It then chdir(2)'s to the project top\ndirectory and runs the given <command>, with <argument> and\nthese canonicalized <path> arguments.\n\nThis is useful for the Porcelain layer to run core GIT commands\nfrom subdirectories.  For example, if linux-2.6.git tree is\nchecked out in /usr/src/linux, you can do:\n\n    $ cd /usr/src/linux/fs\n    $ ... work in fs directory making changes ...\n    $ git-run-with-user-path git-diff-tree -r HEAD -- ext? ../include/linux\n    $ find ext? ! -type d -print0 |\n      xargs -0 git-run-with-user-path git-update-cache --add -- --\n\nThe above is roughly equivalent to:\n\n    $ cd /usr/src/linux\n    $ git-diff-tree -r HEAD fs/ext? include/linux\n    $ find fs/ext? include/linux ! -type d -print0 |\n      xargs git-update-cache --add --\n\nOPTIONS\n-------\n--no-ignore::\n\n\tBy default, the path arguments are filtered with the\n\tsame ignore rules Porcelain layers use.  With\n\t--no-ignore flag, there is no such filtering done.\n\nAuthor\n------\nWritten by Junio C Hamano <junkio@cox.net>\n\nDocumentation\n--------------\nDocumentation by Junio C Hamano.\n\nGIT\n---\nPart of the link:git.html[git] suite\n\n\n"},{"id":"3412","messageId":"pan.2005.05.16.09.35.22.73817@smurf.noris.de","threadId":"591","inReplyTo":"2cfc4032050514181127c02e43@mail.gmail.com","subject":"Re: [RFD] Ignore rules","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-05-16T09:35:22Z","receivedAt":"2005-05-16T09:35:22Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi, Jon Seymour wrote:\n\n> a. pushing the ignore logic into the core git tools such as git-ls-files\n> \n> b. including the current ignore .* rule as a default ignore rule that\n> can be overridden by a .gitignore file\n\nI'd say YES to both.\n\nMy preferred ignore file logic would be:\n\n- stop at first match (that's more efficient)\n- !pattern prevents exclusion of matching files\n- bash-style shell globs, except that ...\n  - a pattern that starts with / is a regexp\n  - * doesn't cross directory boundaries, but ** does\n- I don't need a per-repository (i.e. non-checked-in/propagated)\n  ignore file.\n\n-- \nMatthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de\n\n\n"},{"id":"3416","messageId":"4288C4AD.6060004@dgreaves.com","threadId":"591","inReplyTo":"pan.2005.05.16.09.35.22.73817@smurf.noris.de","subject":"Re: [RFD] Ignore rules","fromName":"David Greaves","fromEmail":"david@dgreaves.com","sentAt":"2005-05-16T16:05:01Z","receivedAt":"2005-05-16T16:05:01Z","isPatch":false,"sender":{"key":"david@dgreaves.com","avatar":"https://gravatar.com/avatar/ca67bad50999edcdd137c9a65da2381557d175bea99ae956afdabc5785e42b79?d=mp&s=160"},"body":"Matthias Urlichs wrote:\n\n>Hi, Jon Seymour wrote:\n>\n>  \n>\n>>a. pushing the ignore logic into the core git tools such as git-ls-files\n>>\n>>b. including the current ignore .* rule as a default ignore rule that\n>>can be overridden by a .gitignore file\n>>    \n>>\n>\n>I'd say YES to both.\n>\n>My preferred ignore file logic would be:\n>\n>- stop at first match (that's more efficient)\n>  \n>\nmore efficient true - but then surely 98% of the time you have to check\n_all_ patterns since files aren't generally ignored.\nAnd the ability to override earlier matches makes life much easier.\nSo I say no shortcuts, last pattern to match decides ignore/accept status\n\n>- !pattern prevents exclusion of matching files\n>- bash-style shell globs, except that ...\n>  - a pattern that starts with / is a regexp\n>  - * doesn't cross directory boundaries, but ** does\n>  \n>\n>- I don't need a per-repository (i.e. non-checked-in/propagated)\n>  ignore file.\n>\nI agree.\nBut for the sake of checking a couple of files it makes sense to define\na complete set of locations.\n\nDavid\n\n\n-- \n\n"}]}