{"thread":{"id":"1290","subject":"[PATCH 1/1] Tell vim the textwidth is 75.","startedAt":"2005-07-21T20:23:10Z","lastAt":"2005-08-01T16:14:37Z","messageCount":55,"participants":["Bryan larsen","Junio C Hamano","Catalin Marinas","Sam Ravnborg","Petr Baudis","Bryan Larsen","Linus Torvalds","A Large Angry SCM","Matthias Urlichs","Wayne Scott"],"isPatch":true,"patchVersion":1,"patchTotal":1},"messages":[{"id":"6299","messageId":"20050721202309.8216.19338.stgit@h164.c77.b0.tor.eicat.ca","threadId":"1290","inReplyTo":null,"subject":"[PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Bryan larsen","fromEmail":"bryanlarsen@yahoo.com","sentAt":"2005-07-21T20:23:10Z","receivedAt":"2005-07-21T20:23:10Z","isPatch":true,"sender":{"key":"bryan@larsen.st","avatar":"https://avatars.githubusercontent.com/u/32073?v=4"},"body":"When invoking EDITOR, add some metadata to tell vim the textwidth is 75.\n\nSigned-off-by: Bryan Larsen <bryan.larsen@gmail.com>\n---\n\n stgit/stack.py |    2 ++\n 1 files changed, 2 insertions(+), 0 deletions(-)\n\ndiff --git a/stgit/stack.py b/stgit/stack.py\n--- a/stgit/stack.py\n+++ b/stgit/stack.py\n@@ -66,6 +66,8 @@ def edit_file(string, comment):\n           % __comment_prefix\n     print >> f, __comment_prefix, \\\n           'Trailing empty lines will be automatically removed.'\n+    print >> f, __comment_prefix, \\\n+          'vim: textwidth=75'\n     f.close()\n \n     # the editor\n"},{"id":"6301","messageId":"7v3bq71rmb.fsf@assigned-by-dhcp.cox.net","threadId":"1290","inReplyTo":"20050721202309.8216.19338.stgit@h164.c77.b0.tor.eicat.ca","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-22T02:50:20Z","receivedAt":"2005-07-22T02:50:20Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I do not do Porcelain, but wouldn't it be nicer if we had a\nPorcelain neutral \"commit log template file\" under $GIT_DIR\nsomewhere?  'vim: textwidth=75' is completely useless for\nsomebody like me (I almost always work inside Emacs).\n\nCogito seems to use $GIT_DIR/commit-template for that purpose.\nCan't users put that \"vim:\" hint there, and if StGIT does not\nuse a commit template, patch it to use the same file as Cogito\ndoes?\n"},{"id":"6304","messageId":"tnx1x5ryvn2.fsf@arm.com","threadId":"1290","inReplyTo":"7v3bq71rmb.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-07-22T10:37:05Z","receivedAt":"2005-07-22T10:37:05Z","isPatch":true,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> I do not do Porcelain, but wouldn't it be nicer if we had a\n> Porcelain neutral \"commit log template file\" under $GIT_DIR\n> somewhere?  'vim: textwidth=75' is completely useless for\n> somebody like me (I almost always work inside Emacs).\n\nStGIT uses .git/patchdescr.tmpl as the template, where people can put\nthe a line like \"STG: vim: textwidth=75\" which will be automatically\nremoved. I won't include this patch since it is up to the user to\ndefine whatever setting he/she wants for his editor (I use emacs\nmyself and add something like \"STG: -*- mode: text; -*-\" on the first\nline)\n\n> Cogito seems to use $GIT_DIR/commit-template for that purpose.\n> Can't users put that \"vim:\" hint there, and if StGIT does not\n> use a commit template, patch it to use the same file as Cogito\n> does?\n\nI would use a neutral commit template, only that it should have a\nneutral prefix as well for the lines to be removed (neither STG nor CG\nbut GIT maybe). The $GIT_DIR/commit-template is fine as a file name.\n\n-- \nCatalin\n"},{"id":"6308","messageId":"20050722192424.GB8556@mars.ravnborg.org","threadId":"1290","inReplyTo":"tnx1x5ryvn2.fsf@arm.com","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Sam Ravnborg","fromEmail":"sam@ravnborg.org","sentAt":"2005-07-22T19:24:24Z","receivedAt":"2005-07-22T19:24:24Z","isPatch":true,"sender":{"key":"sam@ravnborg.org","avatar":"https://gravatar.com/avatar/168a912606ed0742d840bb365e3cc21db390c36531a58341dc7a069cc1f15f62?d=mp&s=160"},"body":"> \n> I would use a neutral commit template, only that it should have a\n> neutral prefix as well for the lines to be removed (neither STG nor CG\n> but GIT maybe). The $GIT_DIR/commit-template is fine as a file name.\n\nHow about $GIT_DIR/commit-template-`basename $EDITOR`\nThen we could have different templates for vim, emacs, kade etc.\n\n\tSam\n"},{"id":"6314","messageId":"7vy87yr2xh.fsf@assigned-by-dhcp.cox.net","threadId":"1290","inReplyTo":"20050722192424.GB8556@mars.ravnborg.org","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-22T20:39:06Z","receivedAt":"2005-07-22T20:39:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sam Ravnborg <sam@ravnborg.org> writes:\n\n>> I would use a neutral commit template, only that it should have a\n>> neutral prefix as well for the lines to be removed (neither STG nor CG\n>> but GIT maybe). The $GIT_DIR/commit-template is fine as a file name.\n>\n> How about $GIT_DIR/commit-template-`basename $EDITOR`\n> Then we could have different templates for vim, emacs, kade etc.\n\nThis brings up a point I have been wanting to see discussed,\ninvolving the core people and the Porcelain people [*1*].\n\nI would like to see Porcelains stay compatible when the do not\nhave to differ.  The commit template [*2*] is one example of\nsuch.  Another example is the \"dontdiff/ignore\" file Pasky\ntalked about in a recent commit log in his Cogito tree [*3*].\n\nPorcelains need to agree on what is placed where and used in\nwhat way.\n\nFirst, I will talk about the \"what\" part.  I can see there are\nvarious \"preference\" items we may want to use:\n\n  - commit template (to enforce a certain style)\n  - standard \"dontdiff/ignore\" file.\n  - pre-commit hook (to enforce a certain tests to pass)\n  - post-commit-hook (sending commit-notification perhaps).\n  - environment overrides (COMMITTER_NAME, COMMITTER_EMAIL and\n    such).\n\nThere may be others.  Many of them would have different origin:\n\n  - Per project.  A project may want to enforce pre-commit hook\n    for all participants;\n\n  - Per user.  A user may want to use different environment\n    settings for different projects [*4*].\n\n  - Per repository (or work tree).  A user may have more than\n    one work tree for the same project, and want to use\n    different \"preference\" items per tree.\n\nPersonally, given the nature of GIT being a distributed system,\nI do not think something like /etc/git.conf (which suggests \"per\nsystem\" configuration) makes much sense; except working around a\nmailhost name configuration, perhaps.\n\nAbout the \"where\" part, one proposal I have off the top of my\nhead is something like this:\n\n  - Have a directory at the root of the tree, \"_git\" (I do not\n    care about the name at this moment.  The point being it can\n    be revision controlled as part of the project and propagate\n    to other repositories), to store per-project configuration.\n\n  - Use $GIT_DIR/conf/ as a convention to store per repository\n    configuration files.  This does not propagate with\n    pulls/pushes/merges across repositories.\n\n  - Use $HOME/.gitrc (could be a directory or a file in .ini\n    style like StGIT uses -- again, I do not care about the\n    details at this moment) to store per-user configuration.\n\nWhich configuration is read first, what can be overridden, and\nif the configuration is cumulative would be specific to each\npreference item, I suspect.  Some project may not want a user to\noverride the pre-commit hooks, for a bad example.  But normally\nthe per-repository one would take precedence over per-user one\nwhich in turn would take precedence over per-project one.\n\n\n[Footnotes]\n\n*1* Technically this does not involve the core at all, but the\ncore people can act as objective, Porcelain-neutral referees.\nThey'll need to know the outcome of the discussion anyway, since\nthey are the ones that end up maintaining the Porcelain-neutral\ntutorial document.\n\n*2* Unless we are talking about the kind that shows and lets you\nedit the diff to be committed, which somebody else's Porcelain\nmay support, that is.\n\n*3* .gitignore in the cwd is used in Cogito, if I am not\nmistaken.\n\n*4* E.g. I would commit for GIT project with junkio@cox.net\nwhile using junio@twinsun.com for my day-job projects.\n"},{"id":"6315","messageId":"20050722204120.GD11916@pasky.ji.cz","threadId":"1290","inReplyTo":"tnx1x5ryvn2.fsf@arm.com","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-22T20:41:20Z","receivedAt":"2005-07-22T20:41:20Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Jul 22, 2005 at 12:37:05PM CEST, I got a letter\nwhere Catalin Marinas <catalin.marinas@gmail.com> told me that...\n> > Cogito seems to use $GIT_DIR/commit-template for that purpose.\n> > Can't users put that \"vim:\" hint there, and if StGIT does not\n> > use a commit template, patch it to use the same file as Cogito\n> > does?\n> \n> I would use a neutral commit template, only that it should have a\n> neutral prefix as well for the lines to be removed (neither STG nor CG\n> but GIT maybe). The $GIT_DIR/commit-template is fine as a file name.\n\nThis unfortunately isn't that simple, since this file substitutes only\nthe\n\n\tCG: -----------------------------------------------------------------------\n\tCG: Lines beginning with the CG: prefix are removed automatically.\n\nsnippet of the file. The trouble is, Cogito autogenerates most of the\nrest of it. Would the acceptable solution be that I would have\n@CG_FILELIST@-style placeholders there, and any tool processing the\nfile would simply drop lines containing @ directives it does not\nunderstand? (@@ is escaped @)\n\nI have nothing against changing the prefix to GIT:.\n\nThen, Cogito's default commit-template would look like\n\n\tGIT: -----------------------------------------------------------------------\n\tGIT: Lines beginning with the GIT: prefix are removed automatically.\n\tGIT:\n\tGIT: Author: @AUTHOR_NAME@\n\tGIT: Email: @AUTHOR_EMAIL@\n\tGIT: Date: @AUTHOR_DATE@\n\tGIT:@CG_SHOWFILES@@CG_NOMERGE@\n\tGIT:@CG_SHOWFILES@@CG_NOMERGE@ By deleting lines beginning with GIT:F, the associated file\n\tGIT:@CG_SHOWFILES@@CG_NOMERGE@ will be removed from the commit list.\n\tGIT:@CG_SHOWFILES@\n\tGIT:@CG_SHOWFILES@ Modified files:\n\tGIT:@CG_SHOWFILES@F   @FILELIST@\n\tGIT: -----------------------------------------------------------------------\n\tGIT: vim: textwidth=75\n\n(where CG_SHOWFILES is defined only when the list of the files is to be\nshown and CG_NOMERGE only when there is no merge going on).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"6317","messageId":"20050722205948.GE11916@pasky.ji.cz","threadId":"1290","inReplyTo":"7vy87yr2xh.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-22T20:59:48Z","receivedAt":"2005-07-22T20:59:48Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Jul 22, 2005 at 10:39:06PM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> Porcelains need to agree on what is placed where and used in\n> what way.\n\nYes, I always try to make things as Cogito-unspecific as possible.\n\n>   - Per user.  A user may want to use different environment\n>     settings for different projects [*4*].\n> \n>   - Per repository (or work tree).  A user may have more than\n>     one work tree for the same project, and want to use\n>     different \"preference\" items per tree.\n\nI wouldn't distinct between those two. You as a user can copy things\naround when you clone the repositories (if you ever do so), or the\nPorcelain can do it, but having global per-user _combined with\nper-project settings sounds nightmarish. After all, how do you identify\na project?  What if projects merge? I wouldn't open this can of worms.\n\nObviously, there have to be just per-user settings (independent of\n\"project\").\n\n> About the \"where\" part, one proposal I have off the top of my\n> head is something like this:\n> \n>   - Have a directory at the root of the tree, \"_git\" (I do not\n>     care about the name at this moment.  The point being it can\n>     be revision controlled as part of the project and propagate\n>     to other repositories), to store per-project configuration.\n\nFine, but I would probably prefer having it hidden. .gitinfo?\n\n>   - Use $GIT_DIR/conf/ as a convention to store per repository\n>     configuration files.  This does not propagate with\n>     pulls/pushes/merges across repositories.\n\nThat's fine by me. I'd prefer the hooks staying in $GIT_DIR/hooks/.\n\n>   - Use $HOME/.gitrc (could be a directory or a file in .ini\n>     style like StGIT uses -- again, I do not care about the\n>     details at this moment) to store per-user configuration.\n\nAs long as I can sanely parse it in shell... ;-)\n\n> Which configuration is read first, what can be overridden, and\n> if the configuration is cumulative would be specific to each\n> preference item, I suspect.  Some project may not want a user to\n> override the pre-commit hooks, for a bad example.  But normally\n> the per-repository one would take precedence over per-user one\n> which in turn would take precedence over per-project one.\n\nWhat about just running all the hooks in the order you specified?\n\n> [Footnotes]\n> \n> *1* Technically this does not involve the core at all, but the\n> core people can act as objective, Porcelain-neutral referees.\n> They'll need to know the outcome of the discussion anyway, since\n> they are the ones that end up maintaining the Porcelain-neutral\n> tutorial document.\n> \n> *2* Unless we are talking about the kind that shows and lets you\n> edit the diff to be committed, which somebody else's Porcelain\n> may support, that is.\n\nFWIW, I'm planning something like this in cg-commit (when called\nexplicitly with -d) in short-term future.\n\n> *3* .gitignore in the cwd is used in Cogito, if I am not\n> mistaken.\n\nYes. There were several discussions about this in the past, with no\nclear outcome, IIRC. I would prefer:\n\n  ~/.git/ignore per-user\n  /.git/ignore per-repository\n  .gitignore per-directory (cummulative with parent directories)\n\nNote that I also want to make use of some special characters in this\nfile. In particular /^# and /^!, to make it at least as powerful as CVS'\nignore.\n\n> *4* E.g. I would commit for GIT project with junkio@cox.net\n> while using junio@twinsun.com for my day-job projects.\n\n.git/author in current Cogito (.git/conf/author or something in the\nBrave New World ;-).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"6318","messageId":"1122066046.7042.1.camel@localhost.localdomain","threadId":"1290","inReplyTo":"20050722192424.GB8556@mars.ravnborg.org","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-07-22T21:00:46Z","receivedAt":"2005-07-22T21:00:46Z","isPatch":true,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On Fri, 2005-07-22 at 19:24 +0000, Sam Ravnborg wrote:\n> > I would use a neutral commit template, only that it should have a\n> > neutral prefix as well for the lines to be removed (neither STG nor CG\n> > but GIT maybe). The $GIT_DIR/commit-template is fine as a file name.\n> \n> How about $GIT_DIR/commit-template-`basename $EDITOR`\n> Then we could have different templates for vim, emacs, kade etc.\n\nI'm not sure this is worth the hassle since a person usually sticks with\none editor, I don't see why one would use different $EDITOR variables\nwith the same project.\n\n-- \nCatalin\n"},{"id":"6322","messageId":"7vr7dqpmm4.fsf@assigned-by-dhcp.cox.net","threadId":"1290","inReplyTo":"20050722204120.GD11916@pasky.ji.cz","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-22T21:16:51Z","receivedAt":"2005-07-22T21:16:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Wonderful start.\n\nLater on, Porcelains could agree on what @TOKEN@ are generally\navailable, and even start using a common script to pre-fill the\ntemplates, like:\n\n  $ git-fill-template-script <template> <output-file> var=val var=val...\n\nIn your example, I see AUTHOR_NAME, AUTHOR_EMAIL, and\nAUTHOR_DATE (I'd use GIT_AUTHOR_NAME etc to match existing\nenvironment variables, though) would be something that are\nprobably common across Porcelains, and the Porcelain would not\neven have to bother passing them as the command argument to\nfill-template.  About FILELIST, the default would be to do\n\"git-diff-cache --name-only HEAD\", but if a Porcelain keeps\ntrack of \"modified\" files differently it can be overridden by\npassing FILELIST as an explicit parameter.\n"},{"id":"6325","messageId":"20050722212725.GJ11916@pasky.ji.cz","threadId":"1290","inReplyTo":"7vr7dqpmm4.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-22T21:27:25Z","receivedAt":"2005-07-22T21:27:25Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Jul 22, 2005 at 11:16:51PM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> Wonderful start.\n> \n> Later on, Porcelains could agree on what @TOKEN@ are generally\n> available, and even start using a common script to pre-fill the\n> templates, like:\n> \n>   $ git-fill-template-script <template> <output-file> var=val var=val...\n> \n> In your example, I see AUTHOR_NAME, AUTHOR_EMAIL, and\n> AUTHOR_DATE (I'd use GIT_AUTHOR_NAME etc to match existing\n> environment variables, though) would be something that are\n> probably common across Porcelains, and the Porcelain would not\n> even have to bother passing them as the command argument to\n> fill-template.\n\nGood idea. More interesting exercise would be to make a script which\nextracts the values back after the user had a chance to touch it.\n\n> About FILELIST, the default would be to do \"git-diff-cache --name-only\n> HEAD\", but if a Porcelain keeps track of \"modified\" files differently\n> it can be overridden by passing FILELIST as an explicit parameter.\n\nCogito shows '[NMD] filename' in place of @FILELIST@.\n\nThis brings me to another subject, M and N are pretty hard to\ndistinguish visually without close inspection of the output. What about\nswitching to use A instead of N everywhere?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"6329","messageId":"1122068634.7042.35.camel@localhost.localdomain","threadId":"1290","inReplyTo":"7vy87yr2xh.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-07-22T21:43:54Z","receivedAt":"2005-07-22T21:43:54Z","isPatch":true,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On Fri, 2005-07-22 at 13:39 -0700, Junio C Hamano wrote:\n> I would like to see Porcelains stay compatible when the do not\n> have to differ.  The commit template [*2*] is one example of\n> such.  \n\nFor StGIT it is not a problem to use any commit template with any\nprefix. It doesn't generate extra lines.\n\nWould such a template only have 'GIT:' prefixed lines? I usually put\nanother line like 'Signed-off-by:', for convenience. The problem with\nStGIT appears when one wants to re-edit the patch description (stg\nrefresh -e), in which case the existing description should be merged\nwith a part of the template (if you want to get the editor setting for\nexample). It doesn't do this since there is no point in getting another\n'Signed...' line in the existing description.\n\n> First, I will talk about the \"what\" part.  I can see there are\n> various \"preference\" items we may want to use:\n> \n>   - commit template (to enforce a certain style)\n\nOK\n\n>   - standard \"dontdiff/ignore\" file.\n\nStGIT currently uses .git/exclude, since I saw it used by cogito. What\nis dontdiff supposed to do? The 'git diff' command only shows the diff\nfor the files added to the repository.\n\n>   - pre-commit hook (to enforce a certain tests to pass)\n>   - post-commit-hook (sending commit-notification perhaps).\n\nOK\n\n>   - environment overrides (COMMITTER_NAME, COMMITTER_EMAIL and\n>     such).\n\nStGIT works the other way around. By default uses the environment, which\ncan be overridden by the stgitrc file. I could change this easily.\n\n> There may be others.  Many of them would have different origin:\n> \n>   - Per project.  A project may want to enforce pre-commit hook\n>     for all participants;\n\nAs Petr said, it's hard to define a project.\n\n>   - Per user.  A user may want to use different environment\n>     settings for different projects [*4*].\n> \n>   - Per repository (or work tree).  A user may have more than\n>     one work tree for the same project, and want to use\n>     different \"preference\" items per tree.\n\nStGIT uses /etc/stgitrc, ~/.stgitrc and .git/stgitrc, the latter\noverriding the former.\n\n> Personally, given the nature of GIT being a distributed system,\n> I do not think something like /etc/git.conf (which suggests \"per\n> system\" configuration) makes much sense; except working around a\n> mailhost name configuration, perhaps.\n\nFor StGIT it makes sense to get some default settings via /etc/stgitrc.\nThere are things like a SMTP server and the diff3 command. These are set\nwhen installing the application and can be overridden in your home\nor .git directories.\n\n> About the \"where\" part, one proposal I have off the top of my\n> head is something like this:\n\nBefore we get to \"where\", we should define the common settings. I think\nthat git should define the common settings for its operations and the\nother tools should follow them.\n\nOnce you get unique settings for an application (like mail templates or\nthree-way merge commands), it's pretty hard to put them in the same\nfile. It would even be confusing for users.\n\n>   - Have a directory at the root of the tree, \"_git\" (I do not\n>     care about the name at this moment.  The point being it can\n>     be revision controlled as part of the project and propagate\n>     to other repositories), to store per-project configuration.\n\nThat's the thing I didn't like in GNU Arch. You modify the file ignoring\nrules for example and the change will be included in the next commit.\nYou could only get some defaults when cloning a repository, otherwise\nonce you have different preferences from the repository's maintainer,\nyou start getting conflicts in the config files.\n\n>   - Use $GIT_DIR/conf/ as a convention to store per repository\n>     configuration files.  This does not propagate with\n>     pulls/pushes/merges across repositories.\n\nThat's fine.\n\n>   - Use $HOME/.gitrc (could be a directory or a file in .ini\n>     style like StGIT uses -- again, I do not care about the\n>     details at this moment) to store per-user configuration.\n\nAgain, having Porcelain specific options mixed in the same file might\nlead to some confusion among users.\n\n> But normally\n> the per-repository one would take precedence over per-user one\n> which in turn would take precedence over per-project one.\n\nWith a note if specifying what a project is.\n\n> *3* .gitignore in the cwd is used in Cogito, if I am not\n> mistaken.\n\nI will to add this to StGIT.\n\n> *4* E.g. I would commit for GIT project with junkio@cox.net\n> while using junio@twinsun.com for my day-job projects.\n\nIn StGIT this is settable via authorname/authoremail in the stgitrc file\nand can be per repository or per user.\n\n-- \nCatalin\n"},{"id":"6342","messageId":"7vu0imh23q.fsf@assigned-by-dhcp.cox.net","threadId":"1290","inReplyTo":"1122068634.7042.35.camel@localhost.localdomain","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-22T23:07:05Z","receivedAt":"2005-07-22T23:07:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Catalin Marinas <catalin.marinas@gmail.com> writes:\n\n> Would such a template only have 'GIT:' prefixed lines? I usually put\n> another line like 'Signed-off-by:', for convenience. The problem with\n> StGIT appears when one wants to re-edit the patch description (stg\n> refresh -e), in which case the existing description should be merged\n> with a part of the template (if you want to get the editor setting for\n> example). It doesn't do this since there is no point in getting another\n> 'Signed...' line in the existing description.\n\nIf signed-off-by is the only thing you are worried about, how\nabout making it not part of the commit template and the message\nuser touches with the editor?  You first look at the user\nconfiguration somewhere to see if the user wants the\nsigned-off-by line to his commits and with what value, and if\nthe last lines of the edit result does not contain that value\n(to avoid duplicates), add it before feeding the message to\ngit-commit-tree.\n\n>>   - standard \"dontdiff/ignore\" file.\n>\n> StGIT currently uses .git/exclude, since I saw it used by cogito. What\n> is dontdiff supposed to do? The 'git diff' command only shows the diff\n> for the files added to the repository.\n\nI see that what I wrote was vague and badly stated.  Please\nforget about my mentioning \"dontdiff\".  What I meant was your\n.git/exclude, Pasky's .gitignore file and friends.\n\n>>   - environment overrides (COMMITTER_NAME, COMMITTER_EMAIL and\n>>     such).\n>\n> StGIT works the other way around. By default uses the environment, which\n> can be overridden by the stgitrc file. I could change this easily.\n\nAgain I was vague, and what you say StGIT does is exactly what I\nmeant.  I have one value in my environment coming from the login\nshell, and a per- repository preference item overrides it to\nsomething else.\n\n>>   - Per project.  A project may want to enforce pre-commit hook\n>>     for all participants;\n>\n> As Petr said, it's hard to define a project.\n\nBy reading the part you talk about your hating tla, I think you\nknow exactly what I mean.\n\nWhen you merge two projects like Linus did between git.git and\ngitk, obviously the person who is merging the two is responsible\nfor merging the per-project default configuration and resolving\nconflicts.  This probably should be overridable by individual\ndevelopers who pull/fetch into their repository by having per-\nrepository configuration.\n\n> For StGIT it makes sense to get some default settings via /etc/stgitrc.\n> There are things like a SMTP server and the diff3 command. These are set\n> when installing the application and can be overridden in your home\n> or .git directories.\n\nExactly, but that is not specific to StGIT, I presume, and I did\nnot want to hear \"``For StGIT'' it makes sense\".  If StGIT needs\nto use \"diff3\" on a system, probably that is because \"merge\" is\nnot available on that system.  In that case,  cogito needs to\nuse it too, doesn't it?\n\nIf we can make users and sysadmins not having to maintain two\nsets of configuration files for two Porcelains, if we\ncan,... that is what I have been trying to address.\n\n> Before we get to \"where\", we should define the common\n> settings. I think that git should define the common settings\n> for its operations and the other tools should follow them.\n\nPersonally, unless it is something very obvious and basic, I do\nnot think the core barebone Porcelain should be inventing\narbitrary conventions and imposing them on other Porcelains.\nFor very basic things I would agree.\n\nI think Petr already started the discussion rolling for commit\ntemplates, and I like his proposal.  For ignore pattern files, I\nthink what Cogito does sounds almost sensible [*1*] and I am\nsure StGIT have something similar.  I do not see Linus and co\njumping up and down saying git-status should detect and show new\nfiles not registered in the cache, so for now I'd propose to\nskip adding this one to the barebone Porcelain (meaning, this is\nan example of not \"git defining the common and others following\nsuite\").\n\n> That's the thing I didn't like in GNU Arch. You modify the file ignoring\n> rules for example and the change will be included in the next commit.\n> You could only get some defaults when cloning a repository, otherwise\n> once you have different preferences from the repository's maintainer,\n> you start getting conflicts in the config files.\n\nThat's why I suggested to have \"_git\" (project wide default)\nseparate from $GIT_DIR/info (repository owner's discretion), the\nlatter overriding the former.\n\n>>   - Use $HOME/.gitrc (could be a directory or a file in .ini\n>>     style like StGIT uses -- again, I do not care about the\n>>     details at this moment) to store per-user configuration.\n>\n> Again, having Porcelain specific options mixed in the same file might\n> lead to some confusion among users.\n\nTrue.  We need to be careful.\n\nOr course, there is an option of not worry about Porcelain\ncompatibilities at all --- which is certainly simpler.  All we\nneed is to make sure they do not use the same filename for\nconflicting purposes.  If everybody feels that way then this\ndiscussion is moot and I apologize for wasting people's time.\n\n[Footnote]\n\n*1* I said \"almost sensible\" but it is not meant to blame Pasky.\nI think the --exclude mechanism in git-ls-files should be\nextended to allow not just the filename-sans-leading-directory\nmatch but a full relative-to-the-project-root path match.  That\nway, cg-status would not have to run around in the tree to find\nindividual .gitignore files.  \n\nPersonally, I think having to have ignore pattern like .cvsignore\nper-directory is simply _ugly_.\n"},{"id":"6344","messageId":"7v8xzyh1ak.fsf@assigned-by-dhcp.cox.net","threadId":"1290","inReplyTo":"20050722212725.GJ11916@pasky.ji.cz","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-22T23:24:35Z","receivedAt":"2005-07-22T23:24:35Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> Cogito shows '[NMD] filename' in place of @FILELIST@.\n\nSounds sensible.  Does it parse it to limit the files to be\ncommitted?\n\n> This brings me to another subject, M and N are pretty hard to\n> distinguish visually without close inspection of the output. What about\n> switching to use A instead of N everywhere?\n\nAlthough I admit that is minor, I've had the same problem, and\nthis sounds like a good idea.\n\nHowever, I'd like to see what the extent of damage would be even\nif everybody agrees this is a good change.  Any one of core\nbarebone Porcelain, Linus git-tools, gitk, gitweb, Cogito, and\nStGIT would have a veto over this kind of change, or at least we\nshould wait until everybody catches up.\n\nIf we all decide to go ahead, the transition would not be so\npainful, since we do not currently say 'A', the Porcelains can\nstart accepting 'A' as synonym for 'N' today, and then later we\ncan change the tools to produce 'A' instead of 'N'.\n"},{"id":"6349","messageId":"20050722235035.GR11916@pasky.ji.cz","threadId":"1290","inReplyTo":"7v8xzyh1ak.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-22T23:50:36Z","receivedAt":"2005-07-22T23:50:36Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Jul 23, 2005 at 01:24:35AM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> Petr Baudis <pasky@suse.cz> writes:\n> \n> > Cogito shows '[NMD] filename' in place of @FILELIST@.\n> \n> Sounds sensible.  Does it parse it to limit the files to be\n> committed?\n\nYes.\n\n> > This brings me to another subject, M and N are pretty hard to\n> > distinguish visually without close inspection of the output. What about\n> > switching to use A instead of N everywhere?\n> \n> Although I admit that is minor, I've had the same problem, and\n> this sounds like a good idea.\n> \n> However, I'd like to see what the extent of damage would be even\n> if everybody agrees this is a good change.  Any one of core\n> barebone Porcelain, Linus git-tools, gitk, gitweb, Cogito, and\n> StGIT would have a veto over this kind of change, or at least we\n> should wait until everybody catches up.\n\nI don't think the situation is so bad. At least in Cogito, there is only\none use of 'N' (and cg-status, but that goes directly to the user), and\nit's likely useless and things would work even with that changing to 'A'\n(nevertheless, I just updated Cogito to accept 'A' at that place as\nwell).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"6372","messageId":"1122108098.6863.38.camel@localhost.localdomain","threadId":"1290","inReplyTo":"7vu0imh23q.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-07-23T08:41:38Z","receivedAt":"2005-07-23T08:41:38Z","isPatch":true,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On Fri, 2005-07-22 at 16:07 -0700, Junio C Hamano wrote:\n> Catalin Marinas <catalin.marinas@gmail.com> writes:\n>\n> If signed-off-by is the only thing you are worried about, how\n> about making it not part of the commit template and the message\n> user touches with the editor?  You first look at the user\n> configuration somewhere to see if the user wants the\n> signed-off-by line to his commits and with what value, and if\n> the last lines of the edit result does not contain that value\n> (to avoid duplicates), add it before feeding the message to\n> git-commit-tree.\n\nThat's an idea.\n\nAnother problem with the template is when one wants a header as well as\nfooter (for things like '-*- mode: text; -*-'). Maybe something like\nbelow would work:\n\nGIT: your header\n@DESCRIPTION@\nGIT: your footer\nGIT: @FILELIST@\n\nwhere @DESCRIPTION@ is either a blank line for cogito or the existing\npatch description for StGIT. One could also add a 'Signed-...' line when\nthe patch is first created (instead of a blank line).\n\nFor StGIT, one could add something like @PATCHNAME@ as well.\n\n> > StGIT currently uses .git/exclude, since I saw it used by cogito. What\n> > is dontdiff supposed to do? The 'git diff' command only shows the diff\n> > for the files added to the repository.\n> \n> I see that what I wrote was vague and badly stated.  Please\n> forget about my mentioning \"dontdiff\".  What I meant was your\n> .git/exclude, Pasky's .gitignore file and friends.\n\n.gitignore are note currently supported by StGIT but I'll add this.\n\n> When you merge two projects like Linus did between git.git and\n> gitk, obviously the person who is merging the two is responsible\n> for merging the per-project default configuration and resolving\n> conflicts.  This probably should be overridable by individual\n> developers who pull/fetch into their repository by having per-\n> repository configuration.\n\nThe problem appears when one upstream maintainer changes the\nconfiguration, should this be merged again? In this case you can get\nconflicts.\n\n> > For StGIT it makes sense to get some default settings via /etc/stgitrc.\n> > There are things like a SMTP server and the diff3 command. These are set\n> > when installing the application and can be overridden in your home\n> > or .git directories.\n> \n> Exactly, but that is not specific to StGIT, I presume, and I did\n> not want to hear \"``For StGIT'' it makes sense\".  If StGIT needs\n> to use \"diff3\" on a system, probably that is because \"merge\" is\n> not available on that system.  In that case,  cogito needs to\n> use it too, doesn't it?\n\nThis is not always the case. With StGIT you can define your own options\nand tools for a three-way merge. This was implemented because Bryan\nLarsen, I think, asked whether a different (smarter) tool could be used.\nOne might also want that when diff3 fails, a xxdiff or emacs should be\nautomatically started for the conflict files.\n\nThis could be simplified if we enforce the presence of a gitmerge.sh\nfile which only calls merge or diff3 by default. Users can create a new\nfile and put it in the $PATH.\n\n> If we can make users and sysadmins not having to maintain two\n> sets of configuration files for two Porcelains, if we\n> can,... that is what I have been trying to address.\n\nThat's probably a good reason. Also people might use 2 Porcelains and\nthe plain git, they could have a common configuration, especially where\nsettings overlap.\n\n> I think Petr already started the discussion rolling for commit\n> templates, and I like his proposal.\n\nI like it too.\n\n> > That's the thing I didn't like in GNU Arch. You modify the file ignoring\n> > rules for example and the change will be included in the next commit.\n> > You could only get some defaults when cloning a repository, otherwise\n> > once you have different preferences from the repository's maintainer,\n> > you start getting conflicts in the config files.\n> \n> That's why I suggested to have \"_git\" (project wide default)\n> separate from $GIT_DIR/info (repository owner's discretion), the\n> latter overriding the former.\n\nThat's OK with one issue - git should be able to exclude _git when\ngenerating a diff between 2 trees, unless one can enforce the _git/*\nfiles to be read-only.\n\nAnother option would be to have .git/info/<branch> and, with cogito for\nexample, .git/info/origin should always be pulled, even if the local\nfiles were modified. You would override these settings\nin .git/info/master. The problem is to define the branches order in\nwhich the settings are read.\n\n> > Again, having Porcelain specific options mixed in the same file might\n> > lead to some confusion among users.\n> \n> True.  We need to be careful.\n\nThis could be avoided by using ini-like files (well, easy to read in\nPython) and have [git] (for the common things like author name),\n[cogito], [stgit] etc. sections.\n\n> Or course, there is an option of not worry about Porcelain\n> compatibilities at all --- which is certainly simpler.  All we\n> need is to make sure they do not use the same filename for\n> conflicting purposes.  If everybody feels that way then this\n> discussion is moot and I apologize for wasting people's time.\n\nI don't think this is a waste of time. It's useful to have at least some\nbasic conventions. StGIT places files all over the place but without any\nconvention, not even a .stgit extension.\n\nThe problem is how much similar we want the Porcelains to be regarding\nthe settings and the templates. For StGIT, it is much simpler to have\nsomething like '%(FILELIST)s' rather than '@FILELIST@' in a template but\nI have not problem with switching to a common syntax. But we should see\nwhat can easily be changed.\n\nI will write a list with what files StGIT uses and where they are placed\nand we can agree on a structure. I think the .git/ directory usage is\nmore important to be clarified than having a common {git,cogito,stgit}rc\nfile.\n\n-- \nCatalin\n"},{"id":"6374","messageId":"20050723090433.GA11814@pasky.ji.cz","threadId":"1290","inReplyTo":"7vu0imh23q.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-23T09:04:33Z","receivedAt":"2005-07-23T09:04:33Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Jul 23, 2005 at 01:07:05AM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> Catalin Marinas <catalin.marinas@gmail.com> writes:\n> \n> > Would such a template only have 'GIT:' prefixed lines? I usually put\n> > another line like 'Signed-off-by:', for convenience. The problem with\n> > StGIT appears when one wants to re-edit the patch description (stg\n> > refresh -e), in which case the existing description should be merged\n> > with a part of the template (if you want to get the editor setting for\n> > example). It doesn't do this since there is no point in getting another\n> > 'Signed...' line in the existing description.\n> \n> If signed-off-by is the only thing you are worried about, how\n> about making it not part of the commit template and the message\n> user touches with the editor?  You first look at the user\n> configuration somewhere to see if the user wants the\n> signed-off-by line to his commits and with what value, and if\n> the last lines of the edit result does not contain that value\n> (to avoid duplicates), add it before feeding the message to\n> git-commit-tree.\n\nI would rather have something universal. Just avoid inserting duplicate\nlines at the bottom.\n\n> >>   - standard \"dontdiff/ignore\" file.\n> >\n> > StGIT currently uses .git/exclude, since I saw it used by cogito. What\n> > is dontdiff supposed to do? The 'git diff' command only shows the diff\n> > for the files added to the repository.\n> \n> I see that what I wrote was vague and badly stated.  Please\n> forget about my mentioning \"dontdiff\".  What I meant was your\n> .git/exclude, Pasky's .gitignore file and friends.\n\nCogito supports .git/exclude too, but I'd rather rename it to\n.git/ignore (or .git/conf/ignore) as well (gradually).\n\n> >>   - environment overrides (COMMITTER_NAME, COMMITTER_EMAIL and\n> >>     such).\n> >\n> > StGIT works the other way around. By default uses the environment, which\n> > can be overridden by the stgitrc file. I could change this easily.\n> \n> Again I was vague, and what you say StGIT does is exactly what I\n> meant.  I have one value in my environment coming from the login\n> shell, and a per- repository preference item overrides it to\n> something else.\n\nI have it the other way around, with the rationale that your default\nsettings should be in your ~/.gitrc, not environment, which is always\nthe highest priority. The simple reason is that how would I apply the\npatches of other people otherwise? Now I do\n\n\tGIT_AUTHOR_NAME=\"Junio C Hamano\" \\\n\t\tGIT_AUTHOR_EMAIL=\"junkio@cox.net\" \\\n\t\tGIT_AUTHOR_DATE=\"2008-04-01 05:12:33\" \\\n\t\tcg-commit\n\nand it makes complete sense to me.\n\n> > For StGIT it makes sense to get some default settings via /etc/stgitrc.\n> > There are things like a SMTP server and the diff3 command. These are set\n> > when installing the application and can be overridden in your home\n> > or .git directories.\n> \n> Exactly, but that is not specific to StGIT, I presume, and I did\n> not want to hear \"``For StGIT'' it makes sense\".  If StGIT needs\n> to use \"diff3\" on a system, probably that is because \"merge\" is\n> not available on that system.  In that case,  cogito needs to\n> use it too, doesn't it?\n\ndiff3 throws its output on stdout, AFAIK.\n\n> If we can make users and sysadmins not having to maintain two\n> sets of configuration files for two Porcelains, if we\n> can,... that is what I have been trying to address.\n\nYes, but it is a bit secondary to me. The most important for me is that\nmeta-files inside the project itself (e.g. .gitignore) should be as\nportable as possible, as that'd be the biggest hurdle. The second\npriority for me is to make ~/.git/ as universal as possible. Having\ncommon per-user/per-system configuration file as well is nice too, but\nnot so crucial.\n\n> > Before we get to \"where\", we should define the common\n> > settings. I think that git should define the common settings\n> > for its operations and the other tools should follow them.\n> \n> Personally, unless it is something very obvious and basic, I do\n> not think the core barebone Porcelain should be inventing\n> arbitrary conventions and imposing them on other Porcelains.\n> For very basic things I would agree.\n> \n> I think Petr already started the discussion rolling for commit\n> templates, and I like his proposal.  For ignore pattern files, I\n> think what Cogito does sounds almost sensible [*1*] and I am\n> sure StGIT have something similar.  I do not see Linus and co\n> jumping up and down saying git-status should detect and show new\n> files not registered in the cache, so for now I'd propose to\n> skip adding this one to the barebone Porcelain (meaning, this is\n> an example of not \"git defining the common and others following\n> suite\").\n\n(Quite some things came to git from Cogito anyway. ;-) And well, that's\ncompletely natural.)\n\n> *1* I said \"almost sensible\" but it is not meant to blame Pasky.\n> I think the --exclude mechanism in git-ls-files should be\n> extended to allow not just the filename-sans-leading-directory\n> match but a full relative-to-the-project-root path match.  That\n> way, cg-status would not have to run around in the tree to find\n> individual .gitignore files.  \n> \n> Personally, I think having to have ignore pattern like .cvsignore\n> per-directory is simply _ugly_.\n\nNo, I think it's great. That increases the locality of things, which is\ngood. Think about it as of variables - it's nicer to have them local.\nAlso, with a central .gitignore file, how do you specify \"Ignore all\n*.html files under Documentation/\" or so? (Without having ** - or you\nneed to support that one too to make the central .gitignore feasible.\nBut I think that in that case, it would depend on the user whether he\ndefines things in the central .gitignore or in subdirectories.)\n\n> >>   - Use $HOME/.gitrc (could be a directory or a file in .ini\n> >>     style like StGIT uses -- again, I do not care about the\n> >>     details at this moment) to store per-user configuration.\n> >\n> > Again, having Porcelain specific options mixed in the same file might\n> > lead to some confusion among users.\n> \n> True.  We need to be careful.\n> \n> Or course, there is an option of not worry about Porcelain\n> compatibilities at all --- which is certainly simpler.  All we\n> need is to make sure they do not use the same filename for\n> conflicting purposes.  If everybody feels that way then this\n> discussion is moot and I apologize for wasting people's time.\n\nI don't think it is moot at all. (But see above - if we can't agree on\neverything, I would much rather have common stuff in the project tree\nthan in ~ - there's not so much trouble of having multiple sets in ~,\nbut it's annoying to have e.g. .stgitignore, .cgignore and .jitignore in\neach directory of the project, and if one project developer moves to\nanother Porcelain, having to add another set of files, and then keeping\nthem all up to date...)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"6378","messageId":"20050723093035.GB11814@pasky.ji.cz","threadId":"1290","inReplyTo":"1122108098.6863.38.camel@localhost.localdomain","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-23T09:30:35Z","receivedAt":"2005-07-23T09:30:35Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Jul 23, 2005 at 10:41:38AM CEST, I got a letter\nwhere Catalin Marinas <catalin.marinas@gmail.com> told me that...\n> Another problem with the template is when one wants a header as well as\n> footer (for things like '-*- mode: text; -*-'). Maybe something like\n> below would work:\n> \n> GIT: your header\n> @DESCRIPTION@\n> GIT: your footer\n> GIT: @FILELIST@\n> \n> where @DESCRIPTION@ is either a blank line for cogito or the existing\n> patch description for StGIT. One could also add a 'Signed-...' line when\n> the patch is first created (instead of a blank line).\n> \n> For StGIT, one could add something like @PATCHNAME@ as well.\n\nGreat idea.\n\n> > When you merge two projects like Linus did between git.git and\n> > gitk, obviously the person who is merging the two is responsible\n> > for merging the per-project default configuration and resolving\n> > conflicts.  This probably should be overridable by individual\n> > developers who pull/fetch into their repository by having per-\n> > repository configuration.\n> \n> The problem appears when one upstream maintainer changes the\n> configuration, should this be merged again? In this case you can get\n> conflicts.\n\nSo you resolve them...? If the upstream keeps doing changes frequent\nenough and large-scale enough to this becoming annoying, something is\nwrong. :-)\n\n> > > That's the thing I didn't like in GNU Arch. You modify the file ignoring\n> > > rules for example and the change will be included in the next commit.\n> > > You could only get some defaults when cloning a repository, otherwise\n> > > once you have different preferences from the repository's maintainer,\n> > > you start getting conflicts in the config files.\n> > \n> > That's why I suggested to have \"_git\" (project wide default)\n> > separate from $GIT_DIR/info (repository owner's discretion), the\n> > latter overriding the former.\n> \n> That's OK with one issue - git should be able to exclude _git when\n> generating a diff between 2 trees, unless one can enforce the _git/*\n> files to be read-only.\n\nWhy? I think those meta-information is important too, and if it differs,\nI want to see it in the diff. Oh, now I see what you mean - to\noptionally exclude it. That would be nice, having --exclude in\ncommon diff options.\n\n> Another option would be to have .git/info/<branch> and, with cogito for\n> example, .git/info/origin should always be pulled, even if the local\n> files were modified. You would override these settings\n> in .git/info/master. The problem is to define the branches order in\n> which the settings are read.\n\nYes, and you may be pulling from multiple branches. I would keep\n.git/info simple and single-instanced. If you want your stuff to\npropagate to others, put it to .gitinfo/.\n\n> > > Again, having Porcelain specific options mixed in the same file might\n> > > lead to some confusion among users.\n> > \n> > True.  We need to be careful.\n> \n> This could be avoided by using ini-like files (well, easy to read in\n> Python) and have [git] (for the common things like author name),\n> [cogito], [stgit] etc. sections.\n\nNow if it is going to look like this, I think separate files would be\nmuch more practical, more effective and likely simpler for the user as\nwell. For Cogito-specific stuff, the user can well dive into\nCogito-specific configuration files, I think. (Well, there's none now;\nthere is .cgrc but that only contains default options for Cogito\ncommands and will stay so; I plan ~/.cg/cogito.conf or something.\nActually, perhaps the Git configuration file should be ~/.git/git.conf -\nit looks cool, doesn't it?)\n\n> The problem is how much similar we want the Porcelains to be regarding\n> the settings and the templates. For StGIT, it is much simpler to have\n> something like '%(FILELIST)s' rather than '@FILELIST@' in a template but\n> I have not problem with switching to a common syntax. But we should see\n> what can easily be changed.\n\nI chose @FILELIST@ only since it is a common convention to have this as\nrewrite placeholders, and I think it's more visually clear than\n%(FILELIST). Were you insisting on the second syntax, I wouldn't have\n%any problem switching, though. Cogito does no @@ rewriting yet.\n\n> I will write a list with what files StGIT uses and where they are placed\n> and we can agree on a structure. I think the .git/ directory usage is\n> more important to be clarified than having a common {git,cogito,stgit}rc\n> file.\n\nAgreed. What Cogito uses:\n\n\t.git/author\tDefault author information in format\n\t\t\t\tPerson Name <email@addy>\n\n\t.git/branch-name\n\t\t\tSymbolic name of the branch of this repository.\n\t\t\tThis is purely descriptive, does not need to be\n\t\t\tunique and is used only in commit-post. I need\n\t\t\tto distinguish commits done in git-pb and Cogito\n\t\t\tso that's the contents of this file in those two\n\t\t\trepositories. Quite ad-hoc and deserves a better\n\t\t\tsolution, but I have none so far; in the future,\n\t\t\tI might just have shared repository for those\n\t\t\ttwo and use the head name.\n\n\t.git/commit-template\n\t\t\tCommit template to use in the commit editor\n\t\t\tinstead of some short header (most of it is\n\t\t\tstill hardcoded).\n\n\t.git/exclude\t--exclude-from for git-ls-files\n\t\t\tI want to rename this to .git/ignore\n\n\t.git/hooks/commit-post\n\t\t\tCOMMIT-ID BRANCHNAME\n\t\t\t(could be <headname> if no branchname defined)\n\n\t.git/hooks/merge-pre\n\t\t\tBRANCHNAME BASE CURHEAD MERGEDHEAD MERGETYPE\n\t\t\tMERGETYPE is either \"forward\" or \"tree\".\n\t\t\tThe merge is cancelled if the script returns\n\t\t\tnon-zero exit code.\n\n\t.git/hooks/merge-post\n\t\t\tBRANCHNAME BASE CURHEAD MERGEDHEAD MERGETYPE STATUS\n\t\t\tMERGETYPE is either \"forward\" or \"tree\".\n\t\t\tFor \"forward\", the STATUS is always \"ok\",\n\t\t\twhile for \"tree\" the STATUS can be\n\t\t\t\"localchanges\", \"conflicts\", \"nocommit\",\n\t\t\tor \"ok\".\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"6380","messageId":"1122114452.6863.72.camel@localhost.localdomain","threadId":"1290","inReplyTo":"20050723093035.GB11814@pasky.ji.cz","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-07-23T10:27:31Z","receivedAt":"2005-07-23T10:27:31Z","isPatch":true,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On Sat, 2005-07-23 at 11:30 +0200, Petr Baudis wrote:\n> Dear diary, on Sat, Jul 23, 2005 at 10:41:38AM CEST, I got a letter\n> where Catalin Marinas <catalin.marinas@gmail.com> told me that...\n> > The problem appears when one upstream maintainer changes the\n> > configuration, should this be merged again? In this case you can get\n> > conflicts.\n> \n> So you resolve them...? If the upstream keeps doing changes frequent\n> enough and large-scale enough to this becoming annoying, something is\n> wrong. :-)\n\nOK, that's fine with me (but see below).\n\n> > That's OK with one issue - git should be able to exclude _git when\n> > generating a diff between 2 trees, unless one can enforce the _git/*\n> > files to be read-only.\n> \n> Why? I think those meta-information is important too, and if it differs,\n> I want to see it in the diff. Oh, now I see what you mean - to\n> optionally exclude it. That would be nice, having --exclude in\n> common diff options.\n\nThat's useful when generating patches.\n\nThe other problem is that the upstream maintainer might not be\ninterested in my own settings but they would be pulled together with the\nnormal data.\n\n> > Another option would be to have .git/info/<branch> and, with cogito for\n> > example, .git/info/origin should always be pulled, even if the local\n> > files were modified. You would override these settings\n> > in .git/info/master. The problem is to define the branches order in\n> > which the settings are read.\n> \n> Yes, and you may be pulling from multiple branches. I would keep\n> .git/info simple and single-instanced. If you want your stuff to\n> propagate to others, put it to .gitinfo/.\n\nYes, my idea complicates things quite a lot.\n\n> > This could be avoided by using ini-like files (well, easy to read in\n> > Python) and have [git] (for the common things like author name),\n> > [cogito], [stgit] etc. sections.\n> \n> Now if it is going to look like this, I think separate files would be\n> much more practical, more effective and likely simpler for the user as\n> well. For Cogito-specific stuff, the user can well dive into\n> Cogito-specific configuration files, I think. (Well, there's none now;\n> there is .cgrc but that only contains default options for Cogito\n> commands and will stay so; I plan ~/.cg/cogito.conf or something.\n> Actually, perhaps the Git configuration file should be ~/.git/git.conf -\n> it looks cool, doesn't it?)\n\nOr we could have ~/.git/git.conf, ~/.git/cogito.conf and\n~/.git/stgit.conf, under the same directory.\n\n> > The problem is how much similar we want the Porcelains to be regarding\n> > the settings and the templates. For StGIT, it is much simpler to have\n> > something like '%(FILELIST)s' rather than '@FILELIST@' in a template but\n> > I have not problem with switching to a common syntax. But we should see\n> > what can easily be changed.\n> \n> I chose @FILELIST@ only since it is a common convention to have this as\n> rewrite placeholders, and I think it's more visually clear than\n> %(FILELIST). Were you insisting on the second syntax, I wouldn't have\n> %any problem switching, though. Cogito does no @@ rewriting yet.\n\nIt's true that @...@ is a common convention and is much clearer. I chose\nmy syntax since it was easier to format the strings in Python. If we go\nfor a common template, I would prefer the @...@ one (and do a regexp\nreplace in Python instead of the string formatting).\n\n> Agreed. What Cogito uses:\n> \n> \t.git/author\tDefault author information in format\n> \t\t\t\tPerson Name <email@addy>\n\nWhat about .git/committer? This is useful if I do a commit at work and I\nwant the repository to have my gmail address.\n\n> \t.git/branch-name\n> \t\t\tSymbolic name of the branch of this repository.\n\nIsn't this the same as $(readlink .git/HEAD), with some trimming?\n\n> \t.git/commit-template\n> \t\t\tCommit template to use in the commit editor\n> \t\t\tinstead of some short header (most of it is\n> \t\t\tstill hardcoded).\n\nOK\n\n> \t.git/exclude\t--exclude-from for git-ls-files\n> \t\t\tI want to rename this to .git/ignore\n\nOK, either name is fine with me.\n\n> \t.git/hooks/commit-post\n> \t.git/hooks/merge-pre\n> \t.git/hooks/merge-post\n\nOK, though StGIT doesn't use any at the moment.\n\nNow, the StGIT files (.git means $GIT_DIR):\n\n      * /etc/stgitrc, ~/.stgitrc, .git/stgitrc - configuration files\n        (the latter overrides the former). The syntax is similar to the\n        ini files\n      * .git/patches/ - directory containing the patch information. I\n        won't go into details here since this is only used by StGIT\n      * .git/exclude - for the files to be ignored by the 'status'\n        command\n      * .git/conflicts - includes the list of files conflicting after a\n        merge operation. The user should run 'stg resolved --all' to\n        mark the conflicts as resolved and remove this file\n      * .git/branches/ - the same meaning as in cogito, only that\n        'master' is considered a branch and 'stg pull' doesn't use\n        'origin'\n      * .git/patchdescr.tmpl - the same idea as commit-template, used\n        when creating the first description for a patch\n      * .git/patchexport.tmpl - template used when exporting the patches\n        in a series\n      * .git/patchmail.tmpl - template used for sending patches by\n        e-mail\n\n-- \nCatalin\n"},{"id":"6381","messageId":"1122114730.6863.76.camel@localhost.localdomain","threadId":"1290","inReplyTo":"7v8xzyh1ak.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-07-23T10:32:10Z","receivedAt":"2005-07-23T10:32:10Z","isPatch":true,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On Fri, 2005-07-22 at 16:24 -0700, Junio C Hamano wrote:\n> Petr Baudis <pasky@suse.cz> writes:\n> > This brings me to another subject, M and N are pretty hard to\n> > distinguish visually without close inspection of the output. What about\n> > switching to use A instead of N everywhere?\n> \n> However, I'd like to see what the extent of damage would be even\n> if everybody agrees this is a good change.\n\nUsing A instead of N is not a problem for StGIT (and I would prefer A\nsince it's easier to read). I could also only change the StGIT output\neven if git uses N.\n\n-- \nCatalin\n"},{"id":"6387","messageId":"42E27155.6070903@yahoo.com","threadId":"1290","inReplyTo":"1122114452.6863.72.camel@localhost.localdomain","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Bryan Larsen","fromEmail":"bryanlarsen@yahoo.com","sentAt":"2005-07-23T16:33:25Z","receivedAt":"2005-07-23T16:33:25Z","isPatch":true,"sender":{"key":"bryan@larsen.st","avatar":"https://avatars.githubusercontent.com/u/32073?v=4"},"body":"Catalin Marinas wrote:\n\nIt seems I inadvertantly kicked off the discussion I wanted to kick off, \nbut I didn't excpect this patch to do so!\n\nI prepared a patch adding the following information into \ngit/Documentation to kick off discussion.  Obviously Catalin is more \nlikely to be accurate.\n\n> \n> OK, though StGIT doesn't use any at the moment.\n> \n> Now, the StGIT files (.git means $GIT_DIR):\n> \n>       * /etc/stgitrc, ~/.stgitrc, .git/stgitrc - configuration files\n>         (the latter overrides the former). The syntax is similar to the\n>         ini files\n>       * .git/patches/ - directory containing the patch information. I\n>         won't go into details here since this is only used by StGIT\n>       * .git/exclude - for the files to be ignored by the 'status'\n>         command\n>       * .git/conflicts - includes the list of files conflicting after a\n>         merge operation. The user should run 'stg resolved --all' to\n>         mark the conflicts as resolved and remove this file\n>       * .git/branches/ - the same meaning as in cogito, only that\n>         'master' is considered a branch and 'stg pull' doesn't use\n>         'origin'\n>       * .git/patchdescr.tmpl - the same idea as commit-template, used\n>         when creating the first description for a patch\n>       * .git/patchexport.tmpl - template used when exporting the patches\n>         in a series\n>       * .git/patchmail.tmpl - template used for sending patches by\n>         e-mail\n> \n\nhow about:\n  .git/refs/heads/master - documented in README, doesn't appear to be used.\n.git/firstmail.tmpl - template used for sending the preamble email\n"},{"id":"6394","messageId":"1122151933.6863.85.camel@localhost.localdomain","threadId":"1290","inReplyTo":"42E27155.6070903@yahoo.com","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-07-23T20:52:13Z","receivedAt":"2005-07-23T20:52:13Z","isPatch":true,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On Sat, 2005-07-23 at 12:33 -0400, Bryan Larsen wrote:\n> how about:\n>   .git/refs/heads/master - documented in README, doesn't appear to be used.\n\nThat's true, README is quite outdated. I created the\nhttp://wiki.procode.org/cgi-bin/wiki.cgi/StGIT page (empty now) where I\nwill add StGIT information and a tutorial. I will probably keep the\nREADME to a minimum and just point people to the wiki page.\n\n> .git/firstmail.tmpl - template used for sending the preamble email\n\nThis file is not used by StGIT. I put it there as an example and you can\nuse it with the --first option of 'mail'. The reason for this is that\nyou need to modify this file every time you send a patch series, unlike\nthe patchmail.tmpl file.\n\n-- \nCatalin\n"},{"id":"6403","messageId":"7vpst9huq2.fsf@assigned-by-dhcp.cox.net","threadId":"1290","inReplyTo":"20050723090433.GA11814@pasky.ji.cz","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-24T01:13:25Z","receivedAt":"2005-07-24T01:13:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> I have it the other way around, with the rationale that your default\n> settings should be in your ~/.gitrc, not environment, which is always\n> the highest priority.\n\nThat's true.  I just never hand commit other people's patches (I\nuse applymbox for that) and never needed to give one-shot set of\nenvironment variables to commit-tree by hand from the command\nline.\n\n> (Quite some things came to git from Cogito anyway. ;-) And well, that's\n> completely natural.)\n\nI am not the one who did the barebone, so I'd let Linus to tell\n\"coming from\" and \"done independently while retaining\ncompatibility\" apart if he wants to ;-).\n\n>> Personally, I think having to have ignore pattern like .cvsignore\n>> per-directory is simply _ugly_.\n>\n> No, I think it's great. That increases the locality of things, which is\n> good. Think about it as of variables - it's nicer to have them local.\n\nSeeing Catalin also expressed the intention to add .gitignore in\ndirectory tree everywhere, I would keep my personal opinion to myself.\n\nHow about we do something like this:\n\n    git-ls-files --others\n        --exclude-from=.git/ignore \\\n    \t--exclude-per-directory=.gitignore\n\nWhen the new flag --exclude-per-directory is specified,\ngit-ls-files uses the file with that name in each directory it\nlooks at to match against the files in that directory (and its\nsubdirectories, perhaps?)  just like it uses --exclude-from for\nthe entire tree today.\n\nIf I added that, would both of you be able to lose a lot of\nlines from cg-status and git.__tree_status()?  If so, then that\nis worth the core-side support.\n\nWhat should the pattern matching rules be?  I think the current\ngit-ls-files one may be a bit too weak.\n"},{"id":"6415","messageId":"7vd5p73jlu.fsf@assigned-by-dhcp.cox.net","threadId":"1290","inReplyTo":"20050722205948.GE11916@pasky.ji.cz","subject":"[RFC] extending git-ls-files --exclude.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-24T22:49:33Z","receivedAt":"2005-07-24T22:49:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> Yes. There were several discussions about this in the past, with no\n> clear outcome, IIRC. I would prefer:\n>\n>   ~/.git/ignore per-user\n>   /.git/ignore per-repository\n>   .gitignore per-directory (cummulative with parent directories)\n>\n> Note that I also want to make use of some special characters in this\n> file ...  to make it at least as powerful as CVS' ignore.\n\nI'd like to extend \"--exclude\" and friends git-ls-files takes\nthe following way (strawman).  I'd appreciate your input from\nthe perspective of Porcelain writers, and somebody who ends up\nhaving to use the bare Plumbing.\n\nI'll be sending patches for actual implementation in separate messages.\n\n------------\n'git-ls-files' can use a list of \"exclude patterns\" when\ntraversing the directory tree and finding files to show when the\nflags --others or --ignored are specified.\n\nThese exclude patterns come from these places:\n\n (1) command line flag --exclude=<pattern> specifies a single\n     pattern.\n\n (2) command line flag --exclude-from=<file> specifies a list of\n     patterns stored in a file.\n\n (3) command line flag --exclude-per-directory=<name> specifies\n     a name of the file in each directory 'git-ls-files'\n     examines, and if exists, its contents are used as an\n     additional list of patterns.\n\nAn exclude pattern file used by (2) and (3) contains one pattern\nper line.  A line that starts with a '#' can be used as comment\nfor readability.\n\nThe list of patterns that is in effect at a given time is\nbuilt and ordered in the following way:\n\n * --exclude=<pattern> and lines read from --exclude-from=<file>\n   come at the beginning of the list of patterns, in the order\n   given on the command line.  Patterns that come from the file\n   specified with --exclude-from are ordered in the same order\n   as they appear in the file.\n\n * When --exclude-per-directory=<name> is specified, upon\n   entering a directory that has such a file, its contents are\n   appended at the end of the current \"list of patterns\".  They\n   are popped off when leaving the directory.\n\nEach pattern in the pattern list specifies \"a match pattern\" and\noptionally the fate --- either a file that matches the pattern\nis considered excluded or included.  By default, this being\n\"exclude\" mechanism, the fate is \"excluded\".  A filename is\nexamined against the patterns in the list, and the first match\ndetermines its fate.\n\nA pattern specified on the command line with --exclude or read\nfrom the file specified with --exclude-from is relative to the\ntop of the directory tree.  A pattern read from a file specified\nby --exclude-per-directory is relative to the directory that the\npattern file appears in.\n\nAn exclude pattern is of the following format:\n\n - an optional prefix '!' which means that the fate this pattern\n   specifies is \"include\", not the usual \"exclude\"; the\n   remainder of the pattern string is interpreted according to\n   the following rules.\n\n - if it does not contain a slash '/', it is a shell glob\n   pattern and used to match against the filename without\n   leading directories (i.e. the same way as the current\n   implementation).\n\n - otherwise, it is a shell glob pattern, suitable for\n   consumption by fnmatch(3) with FNM_PATHNAME flag.  I.e. a\n   slash in the pattern must match a slash in the pathname.\n   \"Documentation/*.html\" matches \"Documentation/git.html\" but\n   not \"ppc/ppc.html\".  As a natural exception, \"/*.c\" matches\n   \"cat-file.c\" but not \"mozilla-sha1/sha1.c\".\n\nAn example: \n\n    $ cat .git/ignore\n    # ignore objects and archives, anywhere in the tree.\n    *.[oa]\n    $ cat Documentation/.gitignore\n    # ignore generated html files,\n    # except foo.html which is maintained by hand\n    !foo.html\n    *.html\n    $ git-ls-files --ignored \\\n        --exclude='Documentation/*.[0-9]' \\\n        --exclude-from=.git/ignore \\\n        --exclude-per-directory=.gitignore\n"},{"id":"6416","messageId":"7v64uz3jji.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1290","inReplyTo":"7vd5p73jlu.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] git-ls-files: --exclude mechanism updates.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-24T22:50:57Z","receivedAt":"2005-07-24T22:50:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Add --exclude-per-directory=<name> option that specifies a file\nto contain exclude patterns local to that directory and its\nsubdirectories.  Update the exclusion logic to be able to say\n\"include files that match this more specific pattern, even\nthough later exclude patterns may match them\".  Also enhances\nthat a pattern can contain '/' in which case fnmatch is called\nwith FNM_PATHNAME flag to match the entire path.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n ls-files.c                         |  123 ++++++++++++++++++++++++++++++------\n t/t3001-ls-files-others-exclude.sh |   55 ++++++++++++++++\n 2 files changed, 157 insertions(+), 21 deletions(-)\n create mode 100755 t/t3001-ls-files-others-exclude.sh\n\nd1466fd8701ca79a91b41c6225c115a0a9866d6e\ndiff --git a/ls-files.c b/ls-files.c\n--- a/ls-files.c\n+++ b/ls-files.c\n@@ -25,20 +25,31 @@ static const char *tag_removed = \"\";\n static const char *tag_other = \"\";\n static const char *tag_killed = \"\";\n \n+static char *exclude_per_dir = NULL;\n static int nr_excludes;\n-static const char **excludes;\n static int excludes_alloc;\n+static struct exclude {\n+\tconst char *pattern;\n+\tconst char *base;\n+\tint baselen;\n+} **excludes;\n \n-static void add_exclude(const char *string)\n+static void add_exclude(const char *string, const char *base, int baselen)\n {\n+\tstruct exclude *x = xmalloc(sizeof (*x));\n+\n+\tx->pattern = string;\n+\tx->base = base;\n+\tx->baselen = baselen;\n \tif (nr_excludes == excludes_alloc) {\n \t\texcludes_alloc = alloc_nr(excludes_alloc);\n \t\texcludes = realloc(excludes, excludes_alloc*sizeof(char *));\n \t}\n-\texcludes[nr_excludes++] = string;\n+\texcludes[nr_excludes++] = x;\n }\n \n-static void add_excludes_from_file(const char *fname)\n+static int add_excludes_from_file_1(const char *fname,\n+\t\t\t\t    const char *base, int baselen)\n {\n \tint fd, i;\n \tlong size;\n@@ -53,7 +64,7 @@ static void add_excludes_from_file(const\n \tlseek(fd, 0, SEEK_SET);\n \tif (size == 0) {\n \t\tclose(fd);\n-\t\treturn;\n+\t\treturn 0;\n \t}\n \tbuf = xmalloc(size);\n \tif (read(fd, buf, size) != size)\n@@ -63,28 +74,89 @@ static void add_excludes_from_file(const\n \tentry = buf;\n \tfor (i = 0; i < size; i++) {\n \t\tif (buf[i] == '\\n') {\n-\t\t\tif (entry != buf + i) {\n+\t\t\tif (entry != buf + i && entry[0] != '#') {\n \t\t\t\tbuf[i] = 0;\n-\t\t\t\tadd_exclude(entry);\n+\t\t\t\tadd_exclude(entry, base, baselen);\n \t\t\t}\n \t\t\tentry = buf + i + 1;\n \t\t}\n \t}\n-\treturn;\n+\treturn 0;\n \n-err:\tperror(fname);\n-\texit(1);\n+ err:\n+\tif (0 <= fd)\n+\t\tclose(fd);\n+\treturn -1;\n+}\n+\n+static void add_excludes_from_file(const char *fname)\n+{\n+\tif (add_excludes_from_file_1(fname, \"\", 0) < 0)\n+\t\tdie(\"cannot use %s as an exclude file\", fname);\n+}\n+\n+static int push_exclude_per_directory(const char *base, int baselen)\n+{\n+\tchar exclude_file[PATH_MAX];\n+\tint current_nr = nr_excludes;\n+\n+\tif (exclude_per_dir) {\n+\t\tmemcpy(exclude_file, base, baselen);\n+\t\tstrcpy(exclude_file + baselen, exclude_per_dir);\n+\t\tadd_excludes_from_file_1(exclude_file, base, baselen);\n+\t}\n+\treturn current_nr;\n+}\n+\n+static void pop_exclude_per_directory(int stk)\n+{\n+\twhile (stk < nr_excludes)\n+\t\tfree(excludes[--nr_excludes]);\n }\n \n static int excluded(const char *pathname)\n {\n \tint i;\n+\n \tif (nr_excludes) {\n-\t\tconst char *basename = strrchr(pathname, '/');\n-\t\tbasename = (basename) ? basename+1 : pathname;\n-\t\tfor (i = 0; i < nr_excludes; i++)\n-\t\t\tif (fnmatch(excludes[i], basename, 0) == 0)\n-\t\t\t\treturn 1;\n+\t\tint pathlen = strlen(pathname);\n+\n+\t\tfor (i = 0; i < nr_excludes; i++) {\n+\t\t\tstruct exclude *x = excludes[i];\n+\t\t\tconst char *exclude = x->pattern;\n+\t\t\tint to_exclude = 1;\n+\n+\t\t\tif (*exclude == '!') {\n+\t\t\t\tto_exclude = 0;\n+\t\t\t\texclude++;\n+\t\t\t}\n+\n+\t\t\tif (!strchr(exclude, '/')) {\n+\t\t\t\t/* match basename */\n+\t\t\t\tconst char *basename = strrchr(pathname, '/');\n+\t\t\t\tbasename = (basename) ? basename+1 : pathname;\n+\t\t\t\tif (fnmatch(exclude, basename, 0) == 0)\n+\t\t\t\t\treturn to_exclude;\n+\t\t\t}\n+\t\t\telse {\n+\t\t\t\t/* match with FNM_PATHNAME:\n+\t\t\t\t * exclude has base (baselen long) inplicitly\n+\t\t\t\t * in front of it.\n+\t\t\t\t */\n+\t\t\t\tint baselen = x->baselen;\n+\t\t\t\tif (*exclude == '/')\n+\t\t\t\t\texclude++;\n+\n+\t\t\t\tif (pathlen < baselen ||\n+\t\t\t\t    (baselen && pathname[baselen-1] != '/') ||\n+\t\t\t\t    strncmp(pathname, x->base, baselen))\n+\t\t\t\t    continue;\n+\n+\t\t\t\tif (fnmatch(exclude, pathname+baselen,\n+\t\t\t\t\t    FNM_PATHNAME) == 0)\n+\t\t\t\t\treturn to_exclude;\n+\t\t\t}\n+\t\t}\n \t}\n \treturn 0;\n }\n@@ -121,7 +193,7 @@ static void add_name(const char *pathnam\n  * doesn't handle them at all yet. Maybe that will change some\n  * day.\n  *\n- * Also, we currently ignore all names starting with a dot.\n+ * Also, we ignore the name \".git\" (even if it is not a directory).\n  * That likely will not change.\n  */\n static void read_directory(const char *path, const char *base, int baselen)\n@@ -129,10 +201,13 @@ static void read_directory(const char *p\n \tDIR *dir = opendir(path);\n \n \tif (dir) {\n+\t\tint exclude_stk;\n \t\tstruct dirent *de;\n \t\tchar fullname[MAXPATHLEN + 1];\n \t\tmemcpy(fullname, base, baselen);\n \n+\t\texclude_stk = push_exclude_per_directory(base, baselen);\n+\n \t\twhile ((de = readdir(dir)) != NULL) {\n \t\t\tint len;\n \n@@ -141,10 +216,10 @@ static void read_directory(const char *p\n \t\t\t     !strcmp(de->d_name + 1, \".\") ||\n \t\t\t     !strcmp(de->d_name + 1, \"git\")))\n \t\t\t\tcontinue;\n-\t\t\tif (excluded(de->d_name) != show_ignored)\n-\t\t\t\tcontinue;\n \t\t\tlen = strlen(de->d_name);\n \t\t\tmemcpy(fullname + baselen, de->d_name, len+1);\n+\t\t\tif (excluded(fullname) != show_ignored)\n+\t\t\t\tcontinue;\n \n \t\t\tswitch (DTYPE(de)) {\n \t\t\tstruct stat st;\n@@ -170,6 +245,8 @@ static void read_directory(const char *p\n \t\t\tadd_name(fullname, baselen + len);\n \t\t}\n \t\tclosedir(dir);\n+\n+\t\tpop_exclude_per_directory(exclude_stk);\n \t}\n }\n \n@@ -287,7 +364,9 @@ static void show_files(void)\n \n static const char *ls_files_usage =\n \t\"git-ls-files [-z] [-t] (--[cached|deleted|others|stage|unmerged|killed])* \"\n-\t\"[ --ignored [--exclude=<pattern>] [--exclude-from=<file>) ]\";\n+\t\"[ --ignored ] [--exclude=<pattern>] [--exclude-from=<file>] \"\n+\t\"[ --exclude-per-directory=<filename> ]\";\n+;\n \n int main(int argc, char **argv)\n {\n@@ -323,13 +402,15 @@ int main(int argc, char **argv)\n \t\t\tshow_stage = 1;\n \t\t\tshow_unmerged = 1;\n \t\t} else if (!strcmp(arg, \"-x\") && i+1 < argc) {\n-\t\t\tadd_exclude(argv[++i]);\n+\t\t\tadd_exclude(argv[++i], \"\", 0);\n \t\t} else if (!strncmp(arg, \"--exclude=\", 10)) {\n-\t\t\tadd_exclude(arg+10);\n+\t\t\tadd_exclude(arg+10, \"\", 0);\n \t\t} else if (!strcmp(arg, \"-X\") && i+1 < argc) {\n \t\t\tadd_excludes_from_file(argv[++i]);\n \t\t} else if (!strncmp(arg, \"--exclude-from=\", 15)) {\n \t\t\tadd_excludes_from_file(arg+15);\n+\t\t} else if (!strncmp(arg, \"--exclude-per-directory=\", 24)) {\n+\t\t\texclude_per_dir = arg + 24;\n \t\t} else\n \t\t\tusage(ls_files_usage);\n \t}\ndiff --git a/t/t3001-ls-files-others-exclude.sh b/t/t3001-ls-files-others-exclude.sh\nnew file mode 100755\n--- /dev/null\n+++ b/t/t3001-ls-files-others-exclude.sh\n@@ -0,0 +1,55 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2005 Junio C Hamano\n+#\n+\n+test_description='git-ls-files --others --exclude\n+\n+This test runs git-ls-files --others and tests --exclude patterns.\n+'\n+\n+. ./test-lib.sh\n+\n+rm -fr one three\n+for dir in . one one/two three\n+do\n+  mkdir -p $dir &&\n+  for i in 1 2 3 4 5\n+  do\n+    >$dir/a.$i\n+  done\n+done\n+\n+cat >expect <<EOF\n+a.2\n+a.4\n+a.5\n+one/a.3\n+one/a.4\n+one/a.5\n+one/two/a.3\n+one/two/a.5\n+three/a.2\n+three/a.3\n+three/a.4\n+three/a.5\n+EOF\n+\n+echo '.gitignore\n+output\n+expect\n+.gitignore\n+' >.git/ignore\n+\n+echo '*.1\n+/*.3' >.gitignore\n+echo '*.2\n+two/*.4' >one/.gitignore\n+\n+test_expect_success \\\n+    'git-ls-files --others --exclude.' \\\n+    'git-ls-files --others \\\n+       --exclude-per-directory=.gitignore \\\n+       --exclude-from=.git/ignore \\\n+       >output &&\n+     diff -u expect output'\n"},{"id":"6417","messageId":"7vwtnf24xx.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1290","inReplyTo":"7vd5p73jlu.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] Documentation: describe git-ls-files --exclude patterns.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-24T22:51:38Z","receivedAt":"2005-07-24T22:51:38Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Signed-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n Documentation/git-ls-files.txt |   96 ++++++++++++++++++++++++++++++++++++++--\n 1 files changed, 92 insertions(+), 4 deletions(-)\n\nd9296497b70d9007da94cec453ecb5c6c7173140\ndiff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt\n--- a/Documentation/git-ls-files.txt\n+++ b/Documentation/git-ls-files.txt\n@@ -14,6 +14,7 @@ SYNOPSIS\n \t\t(-[c|d|o|i|s|u|k])\\*\n \t\t[-x <pattern>|--exclude=<pattern>]\n \t\t[-X <file>|--exclude-from=<file>]\n+\t\t[--exclude-per-directory=<file>]\n \n DESCRIPTION\n -----------\n@@ -59,10 +60,10 @@ OPTIONS\n \n -X|--exclude-from=<file>::\n \texclude patterns are read from <file>; 1 per line.\n-\tAllows the use of the famous dontdiff file as follows to find\n-\tout about uncommitted files just as dontdiff is used with\n-\tthe diff command:\n-\t     git-ls-files --others --exclude-from=dontdiff\n+\n+--exclude-per-directory=<file>::\n+\tread additional exclude patterns that apply only to the\n+\tdirectory and its subdirectories in <file>.\n \n -t::\n \tIdentify the file status with the following tags (followed by\n@@ -89,6 +90,93 @@ the dircache records up to three such pa\n the user (or Cogito) to see what should eventually be recorded at the\n path. (see read-cache for more information on state)\n \n+\n+Exclude Patterns\n+----------------\n+\n+'git-ls-files' can use a list of \"exclude patterns\" when\n+traversing the directory tree and finding files to show when the\n+flags --others or --ignored are specified.\n+\n+These exclude patterns come from these places:\n+\n+ (1) command line flag --exclude=<pattern> specifies a single\n+     pattern.\n+\n+ (2) command line flag --exclude-from=<file> specifies a list of\n+     patterns stored in a file.\n+\n+ (3) command line flag --exclude-per-directory=<name> specifies\n+     a name of the file in each directory 'git-ls-files'\n+     examines, and if exists, its contents are used as an\n+     additional list of patterns.\n+\n+An exclude pattern file used by (2) and (3) contains one pattern\n+per line.  A line that starts with a '#' can be used as comment\n+for readability.\n+\n+The list of patterns that is in effect at a given time is\n+built and ordered in the following way:\n+\n+ * --exclude=<pattern> and lines read from --exclude-from=<file>\n+   come at the beginning of the list of patterns, in the order\n+   given on the command line.  Patterns that come from the file\n+   specified with --exclude-from are ordered in the same order\n+   as they appear in the file.\n+\n+ * When --exclude-per-directory=<name> is specified, upon\n+   entering a directory that has such a file, its contents are\n+   appended at the end of the current \"list of patterns\".  They\n+   are popped off when leaving the directory.\n+\n+Each pattern in the pattern list specifies \"a match pattern\" and\n+optionally the fate --- either a file that matches the pattern\n+is considered excluded or included.  By default, this being\n+\"exclude\" mechanism, the fate is \"excluded\".  A filename is\n+examined against the patterns in the list, and the first match\n+determines its fate.\n+\n+A pattern specified on the command line with --exclude or read\n+from the file specified with --exclude-from is relative to the\n+top of the directory tree.  A pattern read from a file specified\n+by --exclude-per-directory is relative to the directory that the\n+pattern file appears in.\n+\n+An exclude pattern is of the following format:\n+\n+ - an optional prefix '!' which means that the fate this pattern\n+   specifies is \"include\", not the usual \"exclude\"; the\n+   remainder of the pattern string is interpreted according to\n+   the following rules.\n+\n+ - if it does not contain a slash '/', it is a shell glob\n+   pattern and used to match against the filename without\n+   leading directories (i.e. the same way as the current\n+   implementation).\n+\n+ - otherwise, it is a shell glob pattern, suitable for\n+   consumption by fnmatch(3) with FNM_PATHNAME flag.  I.e. a\n+   slash in the pattern must match a slash in the pathname.\n+   \"Documentation/*.html\" matches \"Documentation/git.html\" but\n+   not \"ppc/ppc.html\".  As a natural exception, \"/*.c\" matches\n+   \"cat-file.c\" but not \"mozilla-sha1/sha1.c\".\n+\n+An example:\n+\n+    $ cat .git/ignore\n+    # ignore objects and archives, anywhere in the tree.\n+    *.[oa]\n+    $ cat Documentation/.gitignore\n+    # ignore generated html files,\n+    # except foo.html which is maintained by hand\n+    !foo.html\n+    *.html\n+    $ git-ls-files --ignored \\\n+        --exclude='Documentation/*.[0-9]' \\\n+        --exclude-from=.git/ignore \\\n+        --exclude-per-directory=.gitignore\n+\n+\n See Also\n --------\n link:read-cache.html[read-cache]\n"},{"id":"6431","messageId":"tnxmzobutsf.fsf@arm.com","threadId":"1290","inReplyTo":"7vd5p73jlu.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] extending git-ls-files --exclude.","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-07-25T09:19:44Z","receivedAt":"2005-07-25T09:19:44Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Junio C Hamano <junkio@cox.net> wrote:\n>  * When --exclude-per-directory=<name> is specified, upon\n>    entering a directory that has such a file, its contents are\n>    appended at the end of the current \"list of patterns\".  They\n>    are popped off when leaving the directory.\n[...]\n> A pattern specified on the command line with --exclude or read\n> from the file specified with --exclude-from is relative to the\n> top of the directory tree.  A pattern read from a file specified\n> by --exclude-per-directory is relative to the directory that the\n> pattern file appears in.\n\nI think it would make more sense for the exclude-per-directory\npatterns to be local to that directory only, without recursively\npreserving them for subdirectories. One would, in general, put the\ncommon exclude patterns like *.o *~ etc. in the global file\n(.git/exclude). The patterns local to a directory only (take the\nvmlinux file for example), one would write it in the .gitignore file\nbut this should be used for subdirectories.\n\n> An exclude pattern is of the following format:\n[...]\n\nThat's fine. Actually, the Porcelain would care much about it since it\ngets the information already filtered by git.\n\n>     $ cat Documentation/.gitignore\n>     # ignore generated html files,\n>     # except foo.html which is maintained by hand\n>     !foo.html\n>     *.html\n\nWouldn't it be clearer to have the general rules first (*.html),\noverridden by the more specific ones (!foo.html)? Just my opinion, I\ndon't know what others think.\n\n-- \nCatalin\n"},{"id":"6437","messageId":"7vk6jelkty.fsf@assigned-by-dhcp.cox.net","threadId":"1290","inReplyTo":"tnxmzobutsf.fsf@arm.com","subject":"Re: [RFC] extending git-ls-files --exclude.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-25T19:58:01Z","receivedAt":"2005-07-25T19:58:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Catalin Marinas <catalin.marinas@gmail.com> writes:\n\n> I think it would make more sense for the exclude-per-directory\n> patterns to be local to that directory only, without recursively\n> preserving them for subdirectories.\n\nI personally do not have preference either way, but am slightly\nbiased towards the \"cumulative\" behaviour the patch attempts to\nimplement, which was what Pasky said he wanted to have.\n\n    Date: Fri, 22 Jul 2005 22:59:48 +0200\n    From: Petr Baudis <pasky@suse.cz>\n    Subject: Re: [PATCH 1/1] Tell vim the textwidth is 75.\n    Message-ID: <20050722205948.GE11916@pasky.ji.cz>\n\n    > *3* .gitignore in the cwd is used in Cogito, if I am not\n    > mistaken.\n\n    Yes. There were several discussions about this in the past, with no\n    clear outcome, IIRC. I would prefer:\n\n      ~/.git/ignore per-user\n      /.git/ignore per-repository\n      .gitignore per-directory (cummulative with parent directories)\n\n>> An exclude pattern is of the following format:\n> [...]\n>\n> That's fine. Actually, the Porcelain would care much about it since it\n> gets the information already filtered by git.\n\nYour saying \"fine\" is a relief.  This change aims at helping\nPorcelain people by making it less likely for Porcelain to need\nits own filtering.  As you say, if ls-files filters more than\nthe Porcelain wants, that's a bigger problem.\n\n>>     $ cat Documentation/.gitignore\n>>     # ignore generated html files,\n>>     # except foo.html which is maintained by hand\n>>     !foo.html\n>>     *.html\n>\n> Wouldn't it be clearer to have the general rules first (*.html),\n> overridden by the more specific ones (!foo.html)? Just my opinion, I\n> don't know what others think.\n\nI do not know, either, but I do know it is consistent with the\n\"first match determines fate\" rule and cleaner to implement.\n"},{"id":"6438","messageId":"Pine.LNX.4.58.0507251306420.6074@g5.osdl.org","threadId":"1290","inReplyTo":"7vk6jelkty.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] extending git-ls-files --exclude.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-25T20:09:26Z","receivedAt":"2005-07-25T20:09:26Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 25 Jul 2005, Junio C Hamano wrote:\n> \n> I personally do not have preference either way, but am slightly\n> biased towards the \"cumulative\" behaviour the patch attempts to\n> implement, which was what Pasky said he wanted to have.\n\nI think that makes sense.\n\nImagine, for example, that you have separate subdirectory structures for \nDocumentation and for source - maybe you'd put the \"*.o\" rule in the \nsource directory, and a \"*.1\" rule in the Docs subdirectory.\n\n\t\t\tLinus\n"},{"id":"6439","messageId":"7vll3uk4w7.fsf@assigned-by-dhcp.cox.net","threadId":"1290","inReplyTo":"Pine.LNX.4.58.0507251306420.6074@g5.osdl.org","subject":"Re: [RFC] extending git-ls-files --exclude.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-25T20:27:36Z","receivedAt":"2005-07-25T20:27:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds <torvalds@osdl.org> writes:\n\n> On Mon, 25 Jul 2005, Junio C Hamano wrote:\n>> \n>> I personally do not have preference either way, but am slightly\n>> biased towards the \"cumulative\" behaviour the patch attempts to\n>> implement, which was what Pasky said he wanted to have.\n>\n> I think that makes sense.\n>\n> Imagine, for example, that you have separate subdirectory structures for \n> Documentation and for source - maybe you'd put the \"*.o\" rule in the \n> source directory, and a \"*.1\" rule in the Docs subdirectory.\n\nI imagined it, but it appears to me that this is a bad example.\nMy understanding of what Catalin and the proposed patch\ndisagrees is whether the patterns in .gitignore at the top level\nshould govern files under ppc/ and mozilla-sha1/ subdirectories;\nCatalin thinks they should not.\n\nWhat I meant by \"cumulative\" (now I realize I might have\nmisunderstood what Pasky wanted to mean by that word, though)\nwas not just .gitignore in subdirectory being added, but the\neffect of patterns being added so far, either from the command\nline or by parent directories, last while in the deeper\ndirectories.\n"},{"id":"6440","messageId":"1122324678.6866.5.camel@localhost.localdomain","threadId":"1290","inReplyTo":"7vll3uk4w7.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] extending git-ls-files --exclude.","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-07-25T20:51:18Z","receivedAt":"2005-07-25T20:51:18Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On Mon, 2005-07-25 at 13:27 -0700, Junio C Hamano wrote:\n> Linus Torvalds <torvalds@osdl.org> writes:\n> > Imagine, for example, that you have separate subdirectory structures for \n> > Documentation and for source - maybe you'd put the \"*.o\" rule in the \n> > source directory, and a \"*.1\" rule in the Docs subdirectory.\n> \n> I imagined it, but it appears to me that this is a bad example.\n> My understanding of what Catalin and the proposed patch\n> disagrees is whether the patterns in .gitignore at the top level\n> should govern files under ppc/ and mozilla-sha1/ subdirectories;\n> Catalin thinks they should not.\n\nI really don't have a strong preference for this. Linus' example makes\nsense as well. It's up to you how you implement its behaviour,\nPorcelains shouldn't be affected by this.\n\nSince I'm the only one with this idea, you can forget about it (I don't\nmind :-) ). If others express a preference for this, you could implement\na 'cut' label (similar to Prolog's cut operator) which clears the\npattern stack before diving into subdirectories. Anyway, I don't think\nit's worse the hassle since it might never be used.\n\n-- \nCatalin\n"},{"id":"6441","messageId":"1122325168.6866.14.camel@localhost.localdomain","threadId":"1290","inReplyTo":"7vk6jelkty.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] extending git-ls-files --exclude.","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-07-25T20:59:27Z","receivedAt":"2005-07-25T20:59:27Z","isPatch":false,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"On Mon, 2005-07-25 at 12:58 -0700, Junio C Hamano wrote:\n> Catalin Marinas <catalin.marinas@gmail.com> writes:\n> >> An exclude pattern is of the following format:\n> > [...]\n> >\n> > That's fine. Actually, the Porcelain would care much about it since it\n> > gets the information already filtered by git.\n> \n> Your saying \"fine\" is a relief.  This change aims at helping\n> Porcelain people by making it less likely for Porcelain to need\n> its own filtering. As you say, if ls-files filters more than\n> the Porcelain wants, that's a bigger problem.\n\nI don't plan to add any additional filtering in StGIT. What I meant\nabove was that Porcelain would not care much about the patterns. The\nuser should cope with what git provides, nothing more. With these git\npatches, I think there are enough features for filtering.\n\n> > Wouldn't it be clearer to have the general rules first (*.html),\n> > overridden by the more specific ones (!foo.html)? Just my opinion, I\n> > don't know what others think.\n> \n> I do not know, either, but I do know it is consistent with the\n> \"first match determines fate\" rule and cleaner to implement.\n\nI also don't have a strong preference for this and the \"first match\"\nrule clarifies it (otherwise, you could have pushed them on a list in\nreverse order).\n\n-- \nCatalin\n"},{"id":"6449","messageId":"7vpst6fmif.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1290","inReplyTo":"7v8xzyh1ak.fsf@assigned-by-dhcp.cox.net","subject":"Updating diff-raw status letter to 'A' for added files.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-26T00:18:16Z","receivedAt":"2005-07-26T00:18:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Since both of you seem to be in favor of using 'A' instead of\n'N' for added files in the diff-raw output, here are two patches\nrequesting for test.\n\n  [PATCH] Use symbolic constants for diff-raw status indicators.\n  [PATCH] diff-raw: Use 'A' instead of 'N' for added files.\n"},{"id":"6450","messageId":"7vd5p6fme7.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1290","inReplyTo":"7vpst6fmif.fsf_-_@assigned-by-dhcp.cox.net","subject":"[PATCH 1/2] Use symbolic constants for diff-raw status indicators.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-26T00:20:48Z","receivedAt":"2005-07-26T00:20:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Both Cogito and StGIT prefer to see 'A' for new files.  The\ncurrent 'N' is visually harder to distinguish from 'M', which is\nused for modified files.  Prepare the internals to use symbolic\nconstants to make the change easier.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n diff-helper.c |    3 ++-\n diff.c        |   58 ++++++++++++++++++++++++++++++++-------------------------\n diff.h        |   16 ++++++++++++++++\n 3 files changed, 51 insertions(+), 26 deletions(-)\n\ne7baa4f45f4420a6d2da6a13e8959f8405c3ea19\ndiff --git a/diff-helper.c b/diff-helper.c\n--- a/diff-helper.c\n+++ b/diff-helper.c\n@@ -94,7 +94,8 @@ int main(int ac, const char **av) {\n \t\t\tif (!strchr(\"MCRNDU\", status))\n \t\t\t\tbreak;\n \t\t\ttwo_paths = score = 0;\n-\t\t\tif (status == 'R' || status == 'C')\n+\t\t\tif (status == DIFF_STATUS_RENAMED ||\n+\t\t\t    status == DIFF_STATUS_COPIED)\n \t\t\t\ttwo_paths = 1;\n \n \t\t\t/* pick up score if exists */\ndiff --git a/diff.c b/diff.c\n--- a/diff.c\n+++ b/diff.c\n@@ -617,7 +617,7 @@ static void run_diff(struct diff_filepai\n \tother = (strcmp(name, p->two->path) ? p->two->path : NULL);\n \tone = p->one; two = p->two;\n \tswitch (p->status) {\n-\tcase 'C':\n+\tcase DIFF_STATUS_COPIED:\n \t\tsprintf(msg_,\n \t\t\t\"similarity index %d%%\\n\"\n \t\t\t\"copy from %s\\n\"\n@@ -626,7 +626,7 @@ static void run_diff(struct diff_filepai\n \t\t\tname, other);\n \t\txfrm_msg = msg_;\n \t\tbreak;\n-\tcase 'R':\n+\tcase DIFF_STATUS_RENAMED:\n \t\tsprintf(msg_,\n \t\t\t\"similarity index %d%%\\n\"\n \t\t\t\"rename from %s\\n\"\n@@ -635,7 +635,7 @@ static void run_diff(struct diff_filepai\n \t\t\tname, other);\n \t\txfrm_msg = msg_;\n \t\tbreak;\n-\tcase 'M':\n+\tcase DIFF_STATUS_MODIFIED:\n \t\tif (p->score) {\n \t\t\tsprintf(msg_,\n \t\t\t\t\"dissimilarity index %d%%\",\n@@ -796,10 +796,12 @@ static void diff_flush_raw(struct diff_f\n \t\tstatus[1] = 0;\n \t}\n \tswitch (p->status) {\n-\tcase 'C': case 'R':\n+\tcase DIFF_STATUS_COPIED:\n+\tcase DIFF_STATUS_RENAMED:\n \t\ttwo_paths = 1;\n \t\tbreak;\n-\tcase 'N': case 'D':\n+\tcase DIFF_STATUS_ADDED:\n+\tcase DIFF_STATUS_DELETED:\n \t\ttwo_paths = 0;\n \t\tbreak;\n \tdefault:\n@@ -928,13 +930,13 @@ static void diff_resolve_rename_copy(voi\n \t\tp = q->queue[i];\n \t\tp->status = 0; /* undecided */\n \t\tif (DIFF_PAIR_UNMERGED(p))\n-\t\t\tp->status = 'U';\n+\t\t\tp->status = DIFF_STATUS_UNMERGED;\n \t\telse if (!DIFF_FILE_VALID(p->one))\n-\t\t\tp->status = 'N';\n+\t\t\tp->status = DIFF_STATUS_ADDED;\n \t\telse if (!DIFF_FILE_VALID(p->two))\n-\t\t\tp->status = 'D';\n+\t\t\tp->status = DIFF_STATUS_DELETED;\n \t\telse if (DIFF_PAIR_TYPE_CHANGED(p))\n-\t\t\tp->status = 'T';\n+\t\t\tp->status = DIFF_STATUS_TYPE_CHANGED;\n \n \t\t/* from this point on, we are dealing with a pair\n \t\t * whose both sides are valid and of the same type, i.e.\n@@ -942,7 +944,7 @@ static void diff_resolve_rename_copy(voi\n \t\t */\n \t\telse if (DIFF_PAIR_RENAME(p)) {\n \t\t\tif (p->source_stays) {\n-\t\t\t\tp->status = 'C';\n+\t\t\t\tp->status = DIFF_STATUS_COPIED;\n \t\t\t\tcontinue;\n \t\t\t}\n \t\t\t/* See if there is some other filepair that\n@@ -956,22 +958,22 @@ static void diff_resolve_rename_copy(voi\n \t\t\t\tif (!DIFF_PAIR_RENAME(pp))\n \t\t\t\t\tcontinue; /* not a rename/copy */\n \t\t\t\t/* pp is a rename/copy from the same source */\n-\t\t\t\tp->status = 'C';\n+\t\t\t\tp->status = DIFF_STATUS_COPIED;\n \t\t\t\tbreak;\n \t\t\t}\n \t\t\tif (!p->status)\n-\t\t\t\tp->status = 'R';\n+\t\t\t\tp->status = DIFF_STATUS_RENAMED;\n \t\t}\n \t\telse if (memcmp(p->one->sha1, p->two->sha1, 20) ||\n \t\t\t p->one->mode != p->two->mode)\n-\t\t\tp->status = 'M';\n+\t\t\tp->status = DIFF_STATUS_MODIFIED;\n \t\telse {\n \t\t\t/* This is a \"no-change\" entry and should not\n \t\t\t * happen anymore, but prepare for broken callers.\n \t\t\t */\n \t\t\terror(\"feeding unmodified %s to diffcore\",\n \t\t\t      p->one->path);\n-\t\t\tp->status = 'X';\n+\t\t\tp->status = DIFF_STATUS_UNKNOWN;\n \t\t}\n \t}\n \tdiff_debug_queue(\"resolve-rename-copy done\", q);\n@@ -989,7 +991,7 @@ void diff_flush(int diff_output_style, i\n \tfor (i = 0; i < q->nr; i++) {\n \t\tstruct diff_filepair *p = q->queue[i];\n \t\tif ((diff_output_style == DIFF_FORMAT_NO_OUTPUT) ||\n-\t\t    (p->status == 'X'))\n+\t\t    (p->status == DIFF_STATUS_UNKNOWN))\n \t\t\tcontinue;\n \t\tif (p->status == 0)\n \t\t\tdie(\"internal error in diff-resolve-rename-copy\");\n@@ -1024,15 +1026,17 @@ static void diffcore_apply_filter(const \n \tif (!filter)\n \t\treturn;\n \n-\tif (strchr(filter, 'A')) {\n-\t\t/* All-or-none */\n+\tif (strchr(filter, DIFF_STATUS_FILTER_AON)) {\n \t\tint found;\n \t\tfor (i = found = 0; !found && i < q->nr; i++) {\n \t\t\tstruct diff_filepair *p = q->queue[i];\n-\t\t\tif (((p->status == 'M') &&\n-\t\t\t     ((p->score && strchr(filter, 'B')) ||\n-\t\t\t      (!p->score && strchr(filter, 'M')))) ||\n-\t\t\t    ((p->status != 'M') && strchr(filter, p->status)))\n+\t\t\tif (((p->status == DIFF_STATUS_MODIFIED) &&\n+\t\t\t     ((p->score &&\n+\t\t\t       strchr(filter, DIFF_STATUS_FILTER_BROKEN)) ||\n+\t\t\t      (!p->score &&\n+\t\t\t       strchr(filter, DIFF_STATUS_MODIFIED)))) ||\n+\t\t\t    ((p->status != DIFF_STATUS_MODIFIED) &&\n+\t\t\t     strchr(filter, p->status)))\n \t\t\t\tfound++;\n \t\t}\n \t\tif (found)\n@@ -1050,10 +1054,14 @@ static void diffcore_apply_filter(const \n \t\t/* Only the matching ones */\n \t\tfor (i = 0; i < q->nr; i++) {\n \t\t\tstruct diff_filepair *p = q->queue[i];\n-\t\t\tif (((p->status == 'M') &&\n-\t\t\t     ((p->score && strchr(filter, 'B')) ||\n-\t\t\t      (!p->score && strchr(filter, 'M')))) ||\n-\t\t\t    ((p->status != 'M') && strchr(filter, p->status)))\n+\n+\t\t\tif (((p->status == DIFF_STATUS_MODIFIED) &&\n+\t\t\t     ((p->score &&\n+\t\t\t       strchr(filter, DIFF_STATUS_FILTER_BROKEN)) ||\n+\t\t\t      (!p->score &&\n+\t\t\t       strchr(filter, DIFF_STATUS_MODIFIED)))) ||\n+\t\t\t    ((p->status != DIFF_STATUS_MODIFIED) &&\n+\t\t\t     strchr(filter, p->status)))\n \t\t\t\tdiff_q(&outq, p);\n \t\t\telse\n \t\t\t\tdiff_free_filepair(p);\ndiff --git a/diff.h b/diff.h\n--- a/diff.h\n+++ b/diff.h\n@@ -82,4 +82,20 @@ extern int diff_queue_is_empty(void);\n \n extern void diff_flush(int output_style, int line_terminator);\n \n+/* diff-raw status letters */\n+#define DIFF_STATUS_ADDED\t\t'N'\n+#define DIFF_STATUS_COPIED\t\t'C'\n+#define DIFF_STATUS_DELETED\t\t'D'\n+#define DIFF_STATUS_MODIFIED\t\t'M'\n+#define DIFF_STATUS_RENAMED\t\t'R'\n+#define DIFF_STATUS_TYPE_CHANGED\t'T'\n+#define DIFF_STATUS_UNKNOWN\t\t'X'\n+#define DIFF_STATUS_UNMERGED\t\t'U'\n+\n+/* these are not diff-raw status letters proper, but used by\n+ * diffcore-filter insn to specify additional restrictions.\n+ */\n+#define DIFF_STATUS_FILTER_AON\t\t'A'\n+#define DIFF_STATUS_FILTER_BROKEN\t'B'\n+\n #endif /* DIFF_H */\n"},{"id":"6451","messageId":"7vbr4qfmdq.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1290","inReplyTo":"7vpst6fmif.fsf_-_@assigned-by-dhcp.cox.net","subject":"[PATCH 2/2] diff-raw: Use 'A' instead of 'N' for added files.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-26T00:21:05Z","receivedAt":"2005-07-26T00:21:05Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"This actually changes the diff-raw status letter from N to A\nfor added files.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n diff.h |    2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\nca8c9156f8f980455f64e2cedcf0347328e46029\ndiff --git a/diff.h b/diff.h\n--- a/diff.h\n+++ b/diff.h\n@@ -83,7 +83,7 @@ extern int diff_queue_is_empty(void);\n extern void diff_flush(int output_style, int line_terminator);\n \n /* diff-raw status letters */\n-#define DIFF_STATUS_ADDED\t\t'N'\n+#define DIFF_STATUS_ADDED\t\t'A'\n #define DIFF_STATUS_COPIED\t\t'C'\n #define DIFF_STATUS_DELETED\t\t'D'\n #define DIFF_STATUS_MODIFIED\t\t'M'\n"},{"id":"6509","messageId":"20050728155210.GA17952@pasky.ji.cz","threadId":"1290","inReplyTo":"7vd5p73jlu.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] extending git-ls-files --exclude.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-28T15:52:10Z","receivedAt":"2005-07-28T15:52:10Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"  Hello,\n\n  after skimming through it, I think I completely like what you have\nshown here. I'm only concerned about this:\n\nDear diary, on Mon, Jul 25, 2005 at 12:49:33AM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n>     $ cat Documentation/.gitignore\n>     # ignore generated html files,\n>     # except foo.html which is maintained by hand\n>     !foo.html\n>     *.html\n\n  I think this is wrong, and my brief experiments confirm that. I think\nthat the actually useful semantics of exclusion would be for\n_subsequent_ exclusions, not preliminary ones. You generally don't say\n\"I never want this ignored, but I want the rest of that ignored\", but\n\"I want that ignored, except this\". This also gives you more\nflexibility:\n\n\t*.html\n\t!f*.html\n\tfo*.html\n\nwould ignore *.html and fo*.html, but not any other f*.html filenames.\nBut more importantly,\n\n\t.gitignore: *.txt\n\tDocumentation/.gitignore: !*.txt\n\nwill not work, which was the whole _point_ of the exclusion.\n\nCould we please have this semantics changed for those reasons?\n\nThanks,\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"6511","messageId":"20050728155707.GB17952@pasky.ji.cz","threadId":"1290","inReplyTo":"7vll3uk4w7.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] extending git-ls-files --exclude.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-28T15:57:07Z","receivedAt":"2005-07-28T15:57:07Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Mon, Jul 25, 2005 at 10:27:36PM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> Linus Torvalds <torvalds@osdl.org> writes:\n> \n> > On Mon, 25 Jul 2005, Junio C Hamano wrote:\n> >> \n> >> I personally do not have preference either way, but am slightly\n> >> biased towards the \"cumulative\" behaviour the patch attempts to\n> >> implement, which was what Pasky said he wanted to have.\n> >\n> > I think that makes sense.\n> >\n> > Imagine, for example, that you have separate subdirectory structures for \n> > Documentation and for source - maybe you'd put the \"*.o\" rule in the \n> > source directory, and a \"*.1\" rule in the Docs subdirectory.\n> \n> I imagined it, but it appears to me that this is a bad example.\n> My understanding of what Catalin and the proposed patch\n> disagrees is whether the patterns in .gitignore at the top level\n> should govern files under ppc/ and mozilla-sha1/ subdirectories;\n> Catalin thinks they should not.\n\nThey should. If you don't want them take effect in most of the\ndirectories, you would add them as ./pattern in the parent directory,\nwhile if you want them to take effect in most of the directories, you\nwould exclude them in the ones you don't want the pattern to take effect\nin (if you accept my proposal for ! semantics change).\n\n> What I meant by \"cumulative\" (now I realize I might have\n> misunderstood what Pasky wanted to mean by that word, though)\n> was not just .gitignore in subdirectory being added, but the\n> effect of patterns being added so far, either from the command\n> line or by parent directories, last while in the deeper\n> directories.\n\nYes, that's what I meant.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"6512","messageId":"42E9020F.3080302@gmail.com","threadId":"1290","inReplyTo":"20050728155210.GA17952@pasky.ji.cz","subject":"Re: [RFC] extending git-ls-files --exclude.","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2005-07-28T16:04:31Z","receivedAt":"2005-07-28T16:04:31Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Petr Baudis wrote:\n>   I think this is wrong, and my brief experiments confirm that. I think\n> that the actually useful semantics of exclusion would be for\n> _subsequent_ exclusions, not preliminary ones. You generally don't say\n> \"I never want this ignored, but I want the rest of that ignored\", but\n> \"I want that ignored, except this\". This also gives you more\n> flexibility:\n> \n> \t*.html\n> \t!f*.html\n> \tfo*.html\n> \n> would ignore *.html and fo*.html, but not any other f*.html filenames.\n> But more importantly,\n> \n> \t.gitignore: *.txt\n> \tDocumentation/.gitignore: !*.txt\n> \n> will not work, which was the whole _point_ of the exclusion.\n\nSo you're arguing for \"last match wins\" versus \"first match wins\". I, \npersonally, find the former more natural and easier to debug by hand.\n"},{"id":"6525","messageId":"pan.2005.07.28.19.25.39.562903@smurf.noris.de","threadId":"1290","inReplyTo":"42E9020F.3080302@gmail.com","subject":"Re: [RFC] extending git-ls-files --exclude.","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-07-28T19:25:45Z","receivedAt":"2005-07-28T19:25:45Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi, A Large Angry SCM wrote:\n\n> So you're arguing for \"last match wins\" versus \"first match wins\". I, \n> personally, find the former more natural and easier to debug by hand.\n\nYou know, up until five minutes ago, I thought so too.\n\nHowever ... as a human being, I liik for meaning, not for processing\ninstructions. Thus, reading the list top-down, this\n\n> \t*.html\n> \t!f*.html\n> \tfo*.html\n\nmakes perfect sense to me. (\"Throw away the HTML files. Well, except for\nthose that start with 'f'. Well, *except* for foobar.html or whatever.\")\n\nThe other way round, however, the sequence\n> \tfo*.html\n> \t!f*.html\n> \t*.html\n\nis not immediately understandable in one pass, as the second line makes no\nsense whatsoever without the third one. (\"Throw away foobar.html. Umm,\nwe're keeping everything anyway, so why ... oh, HTML files are junked, OK,\nso ... now ... umm, what did I want to find out in the first place?\")\n\nIt gets even more confusing when you're lazy and omit the .html suffix in\nthe second line.\n\nYMMV, and all that.\n-- \nMatthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\n(It is an old Debian tradition to leave at least twice a year ...)\n\t-- Sven Rudolph\n"},{"id":"6527","messageId":"20050728194748.GD24948@pasky.ji.cz","threadId":"1290","inReplyTo":"1122114452.6863.72.camel@localhost.localdomain","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-28T19:47:49Z","receivedAt":"2005-07-28T19:47:49Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sat, Jul 23, 2005 at 12:27:31PM CEST, I got a letter\nwhere Catalin Marinas <catalin.marinas@gmail.com> told me that...\n> > Agreed. What Cogito uses:\n> > \n> > \t.git/author\tDefault author information in format\n> > \t\t\t\tPerson Name <email@addy>\n> \n> What about .git/committer? This is useful if I do a commit at work and I\n> want the repository to have my gmail address.\n\nThe committer field generally identifies the committer \"physically\", and\nisn't usually overriden. You'll find <xpasky@machine.sinus.cz> in my\ncommitter field, e.g.\n\n> > \t.git/branch-name\n> > \t\t\tSymbolic name of the branch of this repository.\n> \n> Isn't this the same as $(readlink .git/HEAD), with some trimming?\n\nNo, that is something totally separate from the usual concepts of\nbranches and repositories, designed to make it possible to distinguish\nbetween repositories etc. from the outside of the system.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"6540","messageId":"7vack6qrhd.fsf@assigned-by-dhcp.cox.net","threadId":"1290","inReplyTo":"20050728194748.GD24948@pasky.ji.cz","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-29T02:24:30Z","receivedAt":"2005-07-29T02:24:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> The committer field generally identifies the committer \"physically\", and\n> isn't usually overriden. You'll find <xpasky@machine.sinus.cz> in my\n> committer field, e.g.\n\nI do not want to get involved in policy decisions, but for the\nrecord I always hated your commit log for that \"identifies the\ncommitter physically\" approach.\n"},{"id":"6544","messageId":"Pine.LNX.4.58.0507281956510.3307@g5.osdl.org","threadId":"1290","inReplyTo":"7vack6qrhd.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-07-29T02:59:41Z","receivedAt":"2005-07-29T02:59:41Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 28 Jul 2005, Junio C Hamano wrote:\n> \n> I do not want to get involved in policy decisions, but for the\n> record I always hated your commit log for that \"identifies the\n> committer physically\" approach.\n\nWell, I have to say that I find it quite useful myself. I try to commit\nx86 patches to the kernel on an x86 machine (I had better had tested them\nthere), so they usually say \"torvalds@evo.osdl.org\" or \"torvalds@yonah..\",\nwhile my normal patches tend to say \"torvalds@g5..\" since that's my main\nmachine.\n\nSo I tend to not override it, even though none of those are really valid\nemail addresses.\n\n\t\tLinus\n"},{"id":"6546","messageId":"7vack6mcd7.fsf@assigned-by-dhcp.cox.net","threadId":"1290","inReplyTo":"20050728155210.GA17952@pasky.ji.cz","subject":"Re: [RFC] extending git-ls-files --exclude.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-29T05:04:36Z","receivedAt":"2005-07-29T05:04:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> You generally don't say \"I never want this ignored, but I want\n> the rest of that ignored\", but \"I want that ignored, except\n> this\".\n\nOK.\n\n> But more importantly,\n>\n> \t.gitignore: *.txt\n> \tDocumentation/.gitignore: !*.txt\n>\n> will not work, which was the whole _point_ of the exclusion.\n\nI agree that this is a bigger issue.\n\nMy updated proposal is as follows:\n\n * We collect --exclude patterns in \"command line patterns\"\n   list, in the same order as given on the command line.\n\n * We collect patterns read from the files specified with\n   --exclude-from in \"exclude-from patterns\" list, in the same\n   order as given on the command line and the same order\n   patterns appear in the file.\n\n * While we descend the directories, files named by EPD flag, if\n   found, are read from top to bottom and concatenated into the\n   \"per directory patterns\" list.  When leaving the directory,\n   the patterns read from that directory's EPD file are popped\n   off.\n\n * When checking a file to see if it is excluded, we first look\n   at \"exclude-from patterns\" list, then \"per directory\n   patterns\" list, and then \"command line patterns list\", in\n   that order.  The last match wins [*1*].\n\nAn example:\n\nYou have three files in your git source tree and your $HOME:\n\n    git/.gitignore                      lists patterns A and B\n    git/Documentation/.gitignore        lists patterns C and D\n    git/.git/info/ignore                lists patterns E and F\n    $HOME/.gitrc/ignore                 lists patterns G and H\n\nYou say:\n\n    git-ls-files --others \\\n        --exclude=I --exclude=J \\\n        --exclude-from=.git/info/ignore \\\n        --exclude-from=~/.gitrc/ignore \\\n        --exclude-per-directory=.gitignore \\\n\nWhile in git/ directory itself, the following patterns are\nchecked and the last match wins:\n\n    E F G H   A B       I J\n\nWhen we descend into git/Documentation, the list of patterns\nused becomes the following, still the last match wins:\n\n    E F G H   A B C D   I J\n\nThe reason --exclude-from comes first (i.e. having the least say\nin the outcome) and --exclude comes last (i.e. having the most\nsay) is because the former is to give the overall fallback\ndefault, and the latter is the ultimate end user preference.\n\nDoes this sound reasonable?\n\n[Footnote]\n\n*1* In real implementation, I would probably scan in reverse\nfrom the end and stop at the first match, but that is an\nimplementation detail.\n"},{"id":"6552","messageId":"20050729072157.GD24895@pasky.ji.cz","threadId":"1290","inReplyTo":"pan.2005.07.28.19.25.39.562903@smurf.noris.de","subject":"Re: [RFC] extending git-ls-files --exclude.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-29T07:21:57Z","receivedAt":"2005-07-29T07:21:57Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Thu, Jul 28, 2005 at 09:25:45PM CEST, I got a letter\nwhere Matthias Urlichs <smurf@smurf.noris.de> told me that...\n> Hi, A Large Angry SCM wrote:\n> \n> > So you're arguing for \"last match wins\" versus \"first match wins\". I, \n> > personally, find the former more natural and easier to debug by hand.\n> \n> You know, up until five minutes ago, I thought so too.\n\nSo is the Large Angry SCM agreeing with me or not? I wrote long reply to\nhis mail, then reread what he wrote again, and decided that he is\n_agreeing_ with me and you that \"last match wins\" is better. :-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"6554","messageId":"20050729073644.GE24895@pasky.ji.cz","threadId":"1290","inReplyTo":"7vack6mcd7.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] extending git-ls-files --exclude.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-29T07:36:44Z","receivedAt":"2005-07-29T07:36:44Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Jul 29, 2005 at 07:04:36AM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n>  * When checking a file to see if it is excluded, we first look\n>    at \"exclude-from patterns\" list, then \"per directory\n>    patterns\" list, and then \"command line patterns list\", in\n>    that order.  The last match wins [*1*].\n\nHmm. What about just excluding the files according to the order of\nparameters on the command line?\n\nHere, the question is whether the GIT Core tools should provide full\nflexibility and friendness to custom use, or rather serve as tighter\nunifying layer for the porcelains, enforcing certain conventions. That's\nup to you to decide, obviously, but perhaps someone will want to use the\nexclude mechanisms for something else than the \"classic\" other files\nignoring stuff, and generally more flexibility might be better. So I'd\nargue for codifying those conventions at the level of the porcelain\nusers and not enforcing them in git-ls-files itself.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"6555","messageId":"20050729073739.GC5680@kiste.smurf.noris.de","threadId":"1290","inReplyTo":"20050729072157.GD24895@pasky.ji.cz","subject":"Re: [RFC] extending git-ls-files --exclude.","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-07-29T07:37:39Z","receivedAt":"2005-07-29T07:37:39Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi,\n\nPetr Baudis:\n> Dear diary, on Thu, Jul 28, 2005 at 09:25:45PM CEST, I got a letter\n> where Matthias Urlichs <smurf@smurf.noris.de> told me that...\n> > Hi, A Large Angry SCM wrote:\n> > \n> > > So you're arguing for \"last match wins\" versus \"first match wins\". I, \n> > > personally, find the former more natural and easier to debug by hand.\n> > \n> > You know, up until five minutes ago, I thought so too.\n> \n> So is the Large Angry SCM agreeing with me or not? I wrote long reply to\n> his mail, then reread what he wrote again, and decided that he is\n> _agreeing_ with me and you that \"last match wins\" is better. :-)\n> \nBah, I misparsed his sentence (I read \"former\" as \"first wins\"), otherwise\nmy reply would have been worded slightly differently.\n\n-- \nMatthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  smurf@smurf.noris.de\nDisclaimer: The quote was selected randomly. Really. | http://smurf.noris.de\n - -\n\"All these black people are screwing up my democracy.\" - Ian Smith\n"},{"id":"6558","messageId":"7vhdeejbjp.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1290","inReplyTo":"7vack6mcd7.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] ls-files: rework exclude patterns.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-29T07:50:34Z","receivedAt":"2005-07-29T07:50:34Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Pasky and others raised many valid points on the problems\ninitial exclude pattern enhancement work had.  Based on the\nlist discussion, rework the exclude logic to use \"last match\ndetermines its fate\" rule, and order the list by exclude-from\n(the fallback default pattern file), exclude-per-directory\n(shallower to deeper, so deeper ones can override), and then\ncommand line exclude patterns.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n ls-files.c |  100 +++++++++++++++++++++++++++++++++++++++++++-----------------\n 1 files changed, 72 insertions(+), 28 deletions(-)\n\na908ed1b0fed52bfdcfc8b3ada366ce05e44c887\ndiff --git a/ls-files.c b/ls-files.c\n--- a/ls-files.c\n+++ b/ls-files.c\n@@ -26,30 +26,45 @@ static const char *tag_other = \"\";\n static const char *tag_killed = \"\";\n \n static char *exclude_per_dir = NULL;\n-static int nr_excludes;\n-static int excludes_alloc;\n-static struct exclude {\n-\tconst char *pattern;\n-\tconst char *base;\n-\tint baselen;\n-} **excludes;\n \n-static void add_exclude(const char *string, const char *base, int baselen)\n+/* We maintain three exclude pattern lists:\n+ * EXC_CMDL lists patterns explicitly given on the command line.\n+ * EXC_DIRS lists patterns obtained from per-directory ignore files.\n+ * EXC_FILE lists patterns from fallback ignore files.\n+ */\n+#define EXC_CMDL 0\n+#define EXC_DIRS 1\n+#define EXC_FILE 2\n+static struct exclude_list {\n+\tint nr;\n+\tint alloc;\n+\tstruct exclude {\n+\t\tconst char *pattern;\n+\t\tconst char *base;\n+\t\tint baselen;\n+\t} **excludes;\n+} exclude_list[3];\n+\n+static void add_exclude(const char *string, const char *base,\n+\t\t\tint baselen, struct exclude_list *which)\n {\n \tstruct exclude *x = xmalloc(sizeof (*x));\n \n \tx->pattern = string;\n \tx->base = base;\n \tx->baselen = baselen;\n-\tif (nr_excludes == excludes_alloc) {\n-\t\texcludes_alloc = alloc_nr(excludes_alloc);\n-\t\texcludes = realloc(excludes, excludes_alloc*sizeof(char *));\n+\tif (which->nr == which->alloc) {\n+\t\twhich->alloc = alloc_nr(which->alloc);\n+\t\twhich->excludes = realloc(which->excludes,\n+\t\t\t\t\t  which->alloc * sizeof(x));\n \t}\n-\texcludes[nr_excludes++] = x;\n+\twhich->excludes[which->nr++] = x;\n }\n \n static int add_excludes_from_file_1(const char *fname,\n-\t\t\t\t    const char *base, int baselen)\n+\t\t\t\t    const char *base,\n+\t\t\t\t    int baselen,\n+\t\t\t\t    struct exclude_list *which)\n {\n \tint fd, i;\n \tlong size;\n@@ -76,7 +91,7 @@ static int add_excludes_from_file_1(cons\n \t\tif (buf[i] == '\\n') {\n \t\t\tif (entry != buf + i && entry[0] != '#') {\n \t\t\t\tbuf[i] = 0;\n-\t\t\t\tadd_exclude(entry, base, baselen);\n+\t\t\t\tadd_exclude(entry, base, baselen, which);\n \t\t\t}\n \t\t\tentry = buf + i + 1;\n \t\t}\n@@ -91,38 +106,45 @@ static int add_excludes_from_file_1(cons\n \n static void add_excludes_from_file(const char *fname)\n {\n-\tif (add_excludes_from_file_1(fname, \"\", 0) < 0)\n+\tif (add_excludes_from_file_1(fname, \"\", 0,\n+\t\t\t\t     &exclude_list[EXC_FILE]) < 0)\n \t\tdie(\"cannot use %s as an exclude file\", fname);\n }\n \n static int push_exclude_per_directory(const char *base, int baselen)\n {\n \tchar exclude_file[PATH_MAX];\n-\tint current_nr = nr_excludes;\n+\tstruct exclude_list *el = &exclude_list[EXC_DIRS];\n+\tint current_nr = el->nr;\n \n \tif (exclude_per_dir) {\n \t\tmemcpy(exclude_file, base, baselen);\n \t\tstrcpy(exclude_file + baselen, exclude_per_dir);\n-\t\tadd_excludes_from_file_1(exclude_file, base, baselen);\n+\t\tadd_excludes_from_file_1(exclude_file, base, baselen, el);\n \t}\n \treturn current_nr;\n }\n \n static void pop_exclude_per_directory(int stk)\n {\n-\twhile (stk < nr_excludes)\n-\t\tfree(excludes[--nr_excludes]);\n+\tstruct exclude_list *el = &exclude_list[EXC_DIRS];\n+\n+\twhile (stk < el->nr)\n+\t\tfree(el->excludes[--el->nr]);\n }\n \n-static int excluded(const char *pathname)\n+/* Scan the list and let the last match determines the fate.\n+ * Return 1 for exclude, 0 for include and -1 for undecided.\n+ */\n+static int excluded_1(const char *pathname,\n+\t\t      int pathlen,\n+\t\t      struct exclude_list *el)\n {\n \tint i;\n \n-\tif (nr_excludes) {\n-\t\tint pathlen = strlen(pathname);\n-\n-\t\tfor (i = 0; i < nr_excludes; i++) {\n-\t\t\tstruct exclude *x = excludes[i];\n+\tif (el->nr) {\n+\t\tfor (i = el->nr - 1; 0 <= i; i--) {\n+\t\t\tstruct exclude *x = el->excludes[i];\n \t\t\tconst char *exclude = x->pattern;\n \t\t\tint to_exclude = 1;\n \n@@ -158,6 +180,22 @@ static int excluded(const char *pathname\n \t\t\t}\n \t\t}\n \t}\n+\treturn -1; /* undecided */\n+}\n+\n+static int excluded(const char *pathname)\n+{\n+\tint pathlen = strlen(pathname);\n+\tint st;\n+\n+\tfor (st = EXC_CMDL; st <= EXC_FILE; st++) {\n+\t\tswitch (excluded_1(pathname, pathlen, &exclude_list[st])) {\n+\t\tcase 0:\n+\t\t\treturn 0;\n+\t\tcase 1:\n+\t\t\treturn 1;\n+\t\t}\n+\t}\n \treturn 0;\n }\n \n@@ -371,6 +409,7 @@ static const char *ls_files_usage =\n int main(int argc, char **argv)\n {\n \tint i;\n+\tint exc_given = 0;\n \n \tfor (i = 1; i < argc; i++) {\n \t\tchar *arg = argv[i];\n@@ -402,20 +441,25 @@ int main(int argc, char **argv)\n \t\t\tshow_stage = 1;\n \t\t\tshow_unmerged = 1;\n \t\t} else if (!strcmp(arg, \"-x\") && i+1 < argc) {\n-\t\t\tadd_exclude(argv[++i], \"\", 0);\n+\t\t\texc_given = 1;\n+\t\t\tadd_exclude(argv[++i], \"\", 0, &exclude_list[EXC_CMDL]);\n \t\t} else if (!strncmp(arg, \"--exclude=\", 10)) {\n-\t\t\tadd_exclude(arg+10, \"\", 0);\n+\t\t\texc_given = 1;\n+\t\t\tadd_exclude(arg+10, \"\", 0, &exclude_list[EXC_CMDL]);\n \t\t} else if (!strcmp(arg, \"-X\") && i+1 < argc) {\n+\t\t\texc_given = 1;\n \t\t\tadd_excludes_from_file(argv[++i]);\n \t\t} else if (!strncmp(arg, \"--exclude-from=\", 15)) {\n+\t\t\texc_given = 1;\n \t\t\tadd_excludes_from_file(arg+15);\n \t\t} else if (!strncmp(arg, \"--exclude-per-directory=\", 24)) {\n+\t\t\texc_given = 1;\n \t\t\texclude_per_dir = arg + 24;\n \t\t} else\n \t\t\tusage(ls_files_usage);\n \t}\n \n-\tif (show_ignored && !nr_excludes) {\n+\tif (show_ignored && !exc_given) {\n \t\tfprintf(stderr, \"%s: --ignored needs some exclude pattern\\n\",\n \t\t\targv[0]);\n \t\texit(1);\n"},{"id":"6556","messageId":"7vack6jbhf.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1290","inReplyTo":"7vack6mcd7.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] Documentation and tests: ls-files exclude pattern.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-29T07:51:56Z","receivedAt":"2005-07-29T07:51:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Update the tests and documentation to match the new \"last one\ndetermines its fate\" semantics.\n\nSigned-off-by: Junio C Hamano <junkio@cox.net>\n---\n\n Documentation/git-ls-files.txt     |   27 ++++++++++++++-------------\n t/t3001-ls-files-others-exclude.sh |   23 ++++++++++++++++++-----\n 2 files changed, 32 insertions(+), 18 deletions(-)\n\n4ae2315518ee4017c6646a4421cf448297fc6dcc\ndiff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt\n--- a/Documentation/git-ls-files.txt\n+++ b/Documentation/git-ls-files.txt\n@@ -115,14 +115,14 @@ An exclude pattern file used by (2) and \n per line.  A line that starts with a '#' can be used as comment\n for readability.\n \n-The list of patterns that is in effect at a given time is\n-built and ordered in the following way:\n+There are three lists of patterns that are in effect at a given\n+time.  They are built and ordered in the following way:\n \n- * --exclude=<pattern> and lines read from --exclude-from=<file>\n-   come at the beginning of the list of patterns, in the order\n-   given on the command line.  Patterns that come from the file\n-   specified with --exclude-from are ordered in the same order\n-   as they appear in the file.\n+ * --exclude=<pattern> from the command line; patterns are\n+   ordered in the same order as they appear on the command line.\n+\n+ * lines read from --exclude-from=<file>; patterns are ordered\n+   in the same order as they appear in the file.\n \n  * When --exclude-per-directory=<name> is specified, upon\n    entering a directory that has such a file, its contents are\n@@ -130,11 +130,12 @@ built and ordered in the following way:\n    are popped off when leaving the directory.\n \n Each pattern in the pattern list specifies \"a match pattern\" and\n-optionally the fate --- either a file that matches the pattern\n-is considered excluded or included.  By default, this being\n-\"exclude\" mechanism, the fate is \"excluded\".  A filename is\n-examined against the patterns in the list, and the first match\n-determines its fate.\n+optionally the fate;n either a file that matches the pattern is\n+considered excluded or included.  A filename is matched against\n+the patterns in the three lists; the --exclude-from list is\n+checked first, then the --exclude-per-directory list, and then\n+finally the --exclude list. The last match determines its fate.\n+If there is no match in the three lists, the fate is \"included\".\n \n A pattern specified on the command line with --exclude or read\n from the file specified with --exclude-from is relative to the\n@@ -168,9 +169,9 @@ An example:\n     *.[oa]\n     $ cat Documentation/.gitignore\n     # ignore generated html files,\n+    *.html\n     # except foo.html which is maintained by hand\n     !foo.html\n-    *.html\n     $ git-ls-files --ignored \\\n         --exclude='Documentation/*.[0-9]' \\\n         --exclude-from=.git/ignore \\\ndiff --git a/t/t3001-ls-files-others-exclude.sh b/t/t3001-ls-files-others-exclude.sh\n--- a/t/t3001-ls-files-others-exclude.sh\n+++ b/t/t3001-ls-files-others-exclude.sh\n@@ -14,7 +14,7 @@ rm -fr one three\n for dir in . one one/two three\n do\n   mkdir -p $dir &&\n-  for i in 1 2 3 4 5\n+  for i in 1 2 3 4 5 6 7 8\n   do\n     >$dir/a.$i\n   done\n@@ -24,31 +24,44 @@ cat >expect <<EOF\n a.2\n a.4\n a.5\n+a.8\n one/a.3\n one/a.4\n one/a.5\n+one/a.7\n+one/two/a.2\n one/two/a.3\n one/two/a.5\n+one/two/a.7\n+one/two/a.8\n three/a.2\n three/a.3\n three/a.4\n three/a.5\n+three/a.8\n EOF\n \n echo '.gitignore\n output\n expect\n .gitignore\n-' >.git/ignore\n+*.7\n+!*.8' >.git/ignore\n \n echo '*.1\n-/*.3' >.gitignore\n+/*.3\n+!*.6' >.gitignore\n echo '*.2\n-two/*.4' >one/.gitignore\n+two/*.4\n+!*.7\n+*.8' >one/.gitignore\n+echo '!*.2\n+!*.8' >one/two/.gitignore\n \n test_expect_success \\\n-    'git-ls-files --others --exclude.' \\\n+    'git-ls-files --others with various exclude options.' \\\n     'git-ls-files --others \\\n+       --exclude=\\*.6 \\\n        --exclude-per-directory=.gitignore \\\n        --exclude-from=.git/ignore \\\n        >output &&\n"},{"id":"6561","messageId":"7vd5p2hve1.fsf@assigned-by-dhcp.cox.net","threadId":"1290","inReplyTo":"20050729073644.GE24895@pasky.ji.cz","subject":"Re: [RFC] extending git-ls-files --exclude.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-29T08:24:54Z","receivedAt":"2005-07-29T08:24:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> Hmm. What about just excluding the files according to the order of\n> parameters on the command line?\n>\n> Here, the question is whether the GIT Core tools should provide full\n> flexibility and friendness to custom use, or rather serve as tighter\n> unifying layer for the porcelains, enforcing certain conventions.\n\nWhile I would in principle prefer to offer more freedom to shoot\nyourselves in the foot ;-), the pragmatic side of me says too\nmuch flexibility is just asking for trouble with not much\nadditional gain.  For example, your \"generic first, and then\nlist exceptions\" argument convinced me to shelve the \"first\nmatch wins\" rule, but I _could_ have added an extra option to\nallow other Porcelain writers who want to have \"most number of\nmatch wins\" rule while at it.  I didn't.  Let's wait and see if\nsomebody else comes up with a different use scenario that would\nbe useful in real life.\n\nIn the meantime, the current one is clearly broken as you\npointed out, so let's replace it with the updated \"generic rule\nwith the following exceptions\" one.\n"},{"id":"6564","messageId":"20050729084144.GJ24895@pasky.ji.cz","threadId":"1290","inReplyTo":"7vd5p2hve1.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] extending git-ls-files --exclude.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-29T08:41:46Z","receivedAt":"2005-07-29T08:41:46Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Jul 29, 2005 at 10:24:54AM CEST, I got a letter\nwhere Junio C Hamano <junkio@cox.net> told me that...\n> In the meantime, the current one is clearly broken as you\n> pointed out, so let's replace it with the updated \"generic rule\n> with the following exceptions\" one.\n\nThat's fine by me. I would only like to ask the Porcelain authors to\nkeep their git-ls-files exclude parameters order matching the internal\nordering so that when we indeed change it in the future to follow the\ncommandline order, the Porcelains won't break.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"6573","messageId":"tnxfytyey1j.fsf@arm.com","threadId":"1290","inReplyTo":"20050728194748.GD24948@pasky.ji.cz","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-07-29T09:55:52Z","receivedAt":"2005-07-29T09:55:52Z","isPatch":true,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Petr Baudis <pasky@suse.cz> wrote:\n> The committer field generally identifies the committer \"physically\", and\n> isn't usually overriden. You'll find <xpasky@machine.sinus.cz> in my\n> committer field, e.g.\n\nI thought GIT_COMMITTER_{NAME,EMAIL} were added to be able to override\nthe defaults like username@localmachine.\n\nThe latest StGIT snapshot uses, by default, the committer's details\nfor the From: line when sending patches by e-mail, assuming that this\nis a valid e-mail address. One can define his own e-mail template and\nuse a different From: line but I thought it would be simpler to\nprovide some defaults based on this.\n\nIf StGIT users don't like this default template, I can change it.\n\n-- \nCatalin\n"},{"id":"6578","messageId":"20050729111056.GR24895@pasky.ji.cz","threadId":"1290","inReplyTo":"tnxfytyey1j.fsf@arm.com","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-07-29T11:10:56Z","receivedAt":"2005-07-29T11:10:56Z","isPatch":true,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Fri, Jul 29, 2005 at 11:55:52AM CEST, I got a letter\nwhere Catalin Marinas <catalin.marinas@gmail.com> told me that...\n> Petr Baudis <pasky@suse.cz> wrote:\n> > The committer field generally identifies the committer \"physically\", and\n> > isn't usually overriden. You'll find <xpasky@machine.sinus.cz> in my\n> > committer field, e.g.\n> \n> I thought GIT_COMMITTER_{NAME,EMAIL} were added to be able to override\n> the defaults like username@localmachine.\n\nYes, but IIRC only for rather special cases like recommitting older\ncommits, importing from other VCSes, etc.\n\n> The latest StGIT snapshot uses, by default, the committer's details\n> for the From: line when sending patches by e-mail, assuming that this\n> is a valid e-mail address. One can define his own e-mail template and\n> use a different From: line but I thought it would be simpler to\n> provide some defaults based on this.\n\nWhy don't you rather use the GIT_AUTHOR_* variables?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nIf you want the holes in your knowledge showing up try teaching\nsomeone.  -- Alan Cox\n"},{"id":"6583","messageId":"tnx8xzpg592.fsf@arm.com","threadId":"1290","inReplyTo":"20050729111056.GR24895@pasky.ji.cz","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Catalin Marinas","fromEmail":"catalin.marinas@gmail.com","sentAt":"2005-07-29T12:34:49Z","receivedAt":"2005-07-29T12:34:49Z","isPatch":true,"sender":{"key":"catalin.marinas@gmail.com","avatar":null},"body":"Petr Baudis <pasky@suse.cz> wrote:\n> Dear diary, on Fri, Jul 29, 2005 at 11:55:52AM CEST, I got a letter\n> where Catalin Marinas <catalin.marinas@gmail.com> told me that...\n>> The latest StGIT snapshot uses, by default, the committer's details\n>> for the From: line when sending patches by e-mail, assuming that this\n>> is a valid e-mail address. One can define his own e-mail template and\n>> use a different From: line but I thought it would be simpler to\n>> provide some defaults based on this.\n>\n> Why don't you rather use the GIT_AUTHOR_* variables?\n\nIt was simpler since the template variables were based on the patch\ndetails. Anyway, it's not hard to modify.\n\n-- \nCatalin\n"},{"id":"6587","messageId":"42EA33CF.3080302@gmail.com","threadId":"1290","inReplyTo":"20050729072157.GD24895@pasky.ji.cz","subject":"Re: [RFC] extending git-ls-files --exclude.","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2005-07-29T13:49:03Z","receivedAt":"2005-07-29T13:49:03Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Petr Baudis wrote:\n> Dear diary, on Thu, Jul 28, 2005 at 09:25:45PM CEST, I got a letter\n> where Matthias Urlichs <smurf@smurf.noris.de> told me that...\n>>Hi, A Large Angry SCM wrote:\n>>\n>>>So you're arguing for \"last match wins\" versus \"first match wins\". I, \n>>>personally, find the former more natural and easier to debug by hand.\n>>You know, up until five minutes ago, I thought so too.\n> \n> So is the Large Angry SCM agreeing with me or not? I wrote long reply to\n> his mail, then reread what he wrote again, and decided that he is\n> _agreeing_ with me and you that \"last match wins\" is better. :-)\n> \n\n*Oops!*\n\nYes, it looks that way doesn't it. But I had accidentally [*1*] typed \n\"former\" where I wanted \"later\". Either way works as long as it's well \ndocumented/understood.\n\n[*1*] Either too much or too little caffeine at the time I suspect.\n"},{"id":"6616","messageId":"7vslxx6o13.fsf@assigned-by-dhcp.cox.net","threadId":"1290","inReplyTo":"20050729111056.GR24895@pasky.ji.cz","subject":"Re: [PATCH 1/1] Tell vim the textwidth is 75.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-07-30T02:11:36Z","receivedAt":"2005-07-30T02:11:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> Dear diary, on Fri, Jul 29, 2005 at 11:55:52AM CEST, I got a letter\n> where Catalin Marinas <catalin.marinas@gmail.com> told me that...\n>> Petr Baudis <pasky@suse.cz> wrote:\n>> > The committer field generally identifies the committer \"physically\", and\n>> > isn't usually overriden. You'll find <xpasky@machine.sinus.cz> in my\n>> > committer field, e.g.\n>> \n>> I thought GIT_COMMITTER_{NAME,EMAIL} were added to be able to override\n>> the defaults like username@localmachine.\n>\n> Yes, but IIRC only for rather special cases like recommitting older\n> commits, importing from other VCSes, etc.\n\nMy recollection coincides with Catalin.  Special case is when\nyou set it to somebody else, \"logically\" different from you, as\nyou say.  Fixing GECOS fields and mailhost settings as Catalin\nsays is another.\n\nSetting it to something \"physically\" different but still the\nsame you, for example using your work e-mail address when you\nare on your home machine, is not special case at all, but is\nalso a valid use.  However when you start to do that, it may\nbecome unusable as a valid e-mail address you can use for From:\nand/or Sender: fields.\n\n>> The latest StGIT snapshot uses, by default, the committer's details\n>> for the From: line when sending patches by e-mail, assuming that this\n>> is a valid e-mail address. One can define his own e-mail template and\n>> use a different From: line but I thought it would be simpler to\n>> provide some defaults based on this.\n>\n> Why don't you rather use the GIT_AUTHOR_* variables?\n\nI tend to agree.  When forwarding somebody else's commit as a\npatch, you would want to name that author on From: line and make\nyourself Sender:.  Of course, in that case Sender: should be a\nvalid e-mail address for the originating machine; otherwise\nbogus-mail-relay prevention would block your e-mail.  In that\nsense, using COMMITTER to identify you \"physically\" (meaning:\ntied to your identity with that particular machine) would work\nbetter.\n"},{"id":"6714","messageId":"59a6e5830508010914714a1fd6@mail.gmail.com","threadId":"1290","inReplyTo":"7vd5p2hve1.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] extending git-ls-files --exclude.","fromName":"Wayne Scott","fromEmail":"wsc9tt@gmail.com","sentAt":"2005-08-01T16:14:37Z","receivedAt":"2005-08-01T16:14:37Z","isPatch":false,"sender":{"key":"wsc9tt@gmail.com","avatar":"https://gravatar.com/avatar/2418bf5fa7f1625a2b9dd049db4ab56110f561610421d6f2559f7c018ce53eb3?d=mp&s=160"},"body":"On 7/29/05, Junio C Hamano <junkio@cox.net> wrote:\n> While I would in principle prefer to offer more freedom to shoot\n> yourselves in the foot ;-), the pragmatic side of me says too\n> much flexibility is just asking for trouble with not much\n> additional gain.  \n\nFor an example of just how far you can go down the road to mind\nnumbing complexity try reading the rsync manpage about how to exclude\nfiles.\n\n-Wayne\n"}]}