{"thread":{"id":"1386","subject":"Re: Status of git.git repository","startedAt":"2005-08-01T03:29:42Z","lastAt":"2007-01-12T21:33:33Z","messageCount":96,"participants":["Horst von Brand","Johannes Schindelin","Matthias Urlichs","Junio C Hamano","Peter Williams","Linus Torvalds","David Kågedal","Martin Langhoff","Tim Ottinger","H. Peter Anvin","Kay Sievers","Petr Baudis","Horst H. von Brand","Nicolas Pitre","Shawn Pearce","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"6705","messageId":"200508010329.j713Tg76008388@laptop11.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: Status of git.git repository","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-08-01T03:29:42Z","receivedAt":"2005-08-01T03:29:42Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n\n[...]\n\n> By the way, do people mind my posting my own patches to the\n> list? I keep the same in the \"pu\" (proposed updates) branch, so\n> if the list readers think I am just adding noise to the list\n> traffic, I would stop doing so, and instead just invite\n> interested people to browse the \"pu\" branch.\n\nIt's fine with me for you to post your patches here. I'd hope that by\nposting your patches get more review (and might spark ideas elsewhere).\nI.e., open source development, Linus style.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"6921","messageId":"200508080318.j783IJNw012384@laptop11.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: GIT 0.99.4 (preview)","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-08-08T03:18:19Z","receivedAt":"2005-08-08T03:18:19Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"My proposed patch, the description as is is misleading.\n\nThe rest of the .spec file looks sane (yes, I've built my share of RPMs\nover the years).\n\ndiff --git a/git-core.spec.in b/git-core.spec.in\n--- a/git-core.spec.in\n+++ b/git-core.spec.in\n@@ -2,7 +2,7 @@\n Name: \t\tgit-core\n Version: \t@@VERSION@@\n Release: \t1\n-Vendor: \tLinus Torvalds \n+Vendor: \tJunio C Hamano \n Summary: \tGit core and tools\n License: \tGPL\n Group: \t\tDevelopment/Tools\n@@ -13,22 +13,23 @@ BuildRoot:\t%{_tmppath}/%{name}-%{version\n Prereq: \tsh-utils, diffutils, rsync, rcs, mktemp >= 1.5\n \n %description\n-GIT comes in two layers. The bottom layer is merely an extremely fast\n-and flexible filesystem-based database designed to store directory trees\n-with regard to their history. The top layer is a SCM-like tool which\n-enables human beings to work with the database in a manner to a degree\n-similar to other SCM tools (like CVS, BitKeeper or Monotone).\n+This is a stupid (but extremely fast) directory content manager. It\n+doesn't do a whole lot, but what it _does_ do is track directory\n+contents efficiently. It is intended to be the base of an efficient,\n+distributed source code management system. This package includes\n+rudimentary tools that can be used as a SCM, but you should look\n+elsewhere for tools for ordinary humans layered on top of this.\n \n %prep\n %setup -q\n \n %build\n-\n make prefix=%{_prefix} all %{!?_without_docs: doc}\n \n %install\n rm -rf $RPM_BUILD_ROOT\n-make dest=$RPM_BUILD_ROOT prefix=%{_prefix} mandir=%{_mandir} install install-tools %{!?_without_docs: install-doc}\n+make dest=$RPM_BUILD_ROOT prefix=%{_prefix} mandir=%{_mandir} \\\n+ install install-tools %{!?_without_docs: install-doc}\n \n %clean\n rm -rf $RPM_BUILD_ROOT\n@@ -43,7 +44,13 @@ rm -rf $RPM_BUILD_ROOT\n %{!?_without_docs: %{_mandir}/man7/*.7.gz}\n \n %changelog\n+* Sun Aug 07 2005 Horst H. von Brand \n+- Redid the description\n+- Cut overlong make line, loosened changelog a bit\n+- I think Junio (or perhaps OSDL?) should be vendor...\n+\n * Thu Jul 14 2005 Eric Biederman \n - Add the man pages, and the --without docs build option\n+\n * Wed Jul 7 2005 Chris Wright \n - initial git spec file\n\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"7024","messageId":"200508100220.j7A2KNWb005040@laptop11.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: Sanity check of git-commit patch, was Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-08-10T02:20:23Z","receivedAt":"2005-08-10T02:20:23Z","isPatch":true,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> Johannes Schindelin writes:\n> \n> >> True. My bad old habit.\n> >\n> > An elegant method to do that:\n> >\n> > case --some-long-option in \"$1\"*) ..; esac\n> \n> You are almost correct, but you need to realize that I generate\n> that long \"case -s|--s|--so|--som|...\" chain using a script that\n> takes all potential option names as its arguments, and makes\n> case arms that contain only unambiguous ones, so that I can\n> handle --some-long-option and --some-other-long-option sensibly.\n\nMy head spins....\n\nIsn't it easier to just use getopt(1)?\n\n> Also you forgot to grok --some-option-with-args=* in your\n> version ;-).\n\nPlease stop! I'm dizzy already!\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"7025","messageId":"Pine.LNX.4.63.0508101451200.19746@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1386","inReplyTo":"200508100220.j7A2KNWb005040@laptop11.inf.utfsm.cl","subject":"Re: Sanity check of git-commit patch, was Re: [PATCH] Making CFLAGS compilant with GNU Coding Standards","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-08-10T12:52:25Z","receivedAt":"2005-08-10T12:52:25Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 9 Aug 2005, Horst von Brand wrote:\n\n> Isn't it easier to just use getopt(1)?\n\nOnly if GNU getopt is available. On Mac OS X, only the BSD version is \ninstalled by default, which does not handle long options at all.\n\n> Please stop! I'm dizzy already!\n\n:-)\n\nCiao,\nDscho\n"},{"id":"7375","messageId":"200508161941.j7GJfpI3023107@laptop11.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: Git 1.0 Synopis (Draft v4)","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-08-16T19:41:51Z","receivedAt":"2005-08-16T19:41:51Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n\n[...]\n\n> - Oh, another itch I did not list in the previous message. Is\n> anybody interested in doing an Emacs VC back-end for GIT?\n\nAnd teach make(1) about checking out files from git... or just create a\nco(1) command for git.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"7379","messageId":"Pine.LNX.4.63.0508162240060.19656@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1386","inReplyTo":"200508161941.j7GJfpI3023107@laptop11.inf.utfsm.cl","subject":"Re: Git 1.0 Synopis (Draft v4)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-08-16T20:41:00Z","receivedAt":"2005-08-16T20:41:00Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 16 Aug 2005, Horst von Brand wrote:\n\n> And teach make(1) about checking out files from git... or just create a\n> co(1) command for git.\n\nHow about \"git-checkout-script\", optionally with the \"-f\" flag to ignore \nchanges since the last checkout/checkin?\n\nCiao,\nDscho\n"},{"id":"7492","messageId":"pan.2005.08.18.09.27.42.884179@smurf.noris.de","threadId":"1386","inReplyTo":"200508161941.j7GJfpI3023107@laptop11.inf.utfsm.cl","subject":"Re: Git 1.0 Synopis (Draft v4)","fromName":"Matthias Urlichs","fromEmail":"smurf@smurf.noris.de","sentAt":"2005-08-18T09:27:44Z","receivedAt":"2005-08-18T09:27:44Z","isPatch":false,"sender":{"key":"matthias@urlichs.de","avatar":"https://gravatar.com/avatar/2708905af227313eba6f2b2ae0f7d0259b5ac5d71baef58fe5a13c699ce0bbf0?d=mp&s=160"},"body":"Hi, Horst von Brand wrote:\n\n> And teach make(1) about checking out files from git... or just create a\n> co(1) command for git.\n\nUmmm... why?\n\nmake's SCCS support depends on the presence of a SCCS/s. file\nfor each . We don't have that. Teaching make about git would be\nequivalent to teaching it about parsing the index file.\n\nTechnically, that would require a stable libgit.so or so.\nIn reality, however, I don't know when I last had a tree which wasn't\nfully populated, but it's been a while, and it's something that can be\nreadily fixed by \"git-checkout-cache -a\".\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 - -\nOne possible reason that things aren't going according to plan\nis that there never was a plan in the first place.\n"},{"id":"8018","messageId":"200509020150.j821oXXM006699@laptop11.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-09-02T01:50:33Z","receivedAt":"2005-09-02T01:50:33Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> Tim Ottinger writes:\n> > git-update-cache for instance?\n> > I am not sure which 'cache' commands need to be 'index' now.\n\n> Logically you are right, but I suspect that may not fly well in\n> practice. Too many of us have already got our fingers wired to\n> type cache, and the glossary is there to describe both cache and\n> index.\n\nI'd vote for cleaning it up /now/. Sure, it will hurt, but if you let time\ngo by and do it later, it will hurt much more.\n\nPre-1.0 is the last chance, AFAICS.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"8065","messageId":"200509042143.j84LhDZo020359@laptop11.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-09-04T21:43:13Z","receivedAt":"2005-09-04T21:43:13Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> I said:\n> \n> > \tI'll draw up a strawman tonight unless somebody else\n> > \tdoes it first.\n\n[...]\n\n> 3. Non-binaries are called '*-scripts'.\n> \n> In earlier discussions some people seem to like the\n> distinction between *-script and others; I did not\n> particularly like it, but I am throwing this in for\n> discussion.\n\nI for one think this makes the command name dependent on a non-essential\nimplementation detail, so -script should go.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"8066","messageId":"7vmzmsbcuc.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"200509042143.j84LhDZo020359@laptop11.inf.utfsm.cl","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-05T00:03:07Z","receivedAt":"2005-09-05T00:03:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Horst von Brand writes:\n\n>> 3. Non-binaries are called '*-scripts'.\n>> \n>> In earlier discussions some people seem to like the\n>> distinction between *-script and others; I did not\n>> particularly like it, but I am throwing this in for\n>> discussion.\n>\n> I for one think this makes the command name dependent on a non-essential\n> implementation detail, so -script should go.\n\nI had the same opinion. The counter-argument people raised when\nthis topic came up on the list was that it would help grepping\nin the source tree.\n\nI'm tempted to suggest doing something along these lines:\n\n - Rename things that are implemented in shell from *-script to\n *.sh, and perl to *.perl in the source tree;\n\n - Install them without .{sh,perl} suffix.\n\nOnce this is done, the users nor the 'git' wrapper do not have\nto deal with *-script.\n\nComments?\n"},{"id":"8067","messageId":"431B90B9.4000108@bigpond.net.au","threadId":"1386","inReplyTo":"7vmzmsbcuc.fsf@assigned-by-dhcp.cox.net","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Peter Williams","fromEmail":"pwil3058@bigpond.net.au","sentAt":"2005-09-05T00:26:33Z","receivedAt":"2005-09-05T00:26:33Z","isPatch":false,"sender":{"key":"pwil3058@bigpond.net.au","avatar":"https://gravatar.com/avatar/fc711ad9d9890c01c6ede5a99a62a8b8ca82a3eef0def8ef98e0ec7da7f99367?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Horst von Brand writes:\n> \n> \n>>>3. Non-binaries are called '*-scripts'.\n>>>\n>>> In earlier discussions some people seem to like the\n>>> distinction between *-script and others; I did not\n>>> particularly like it, but I am throwing this in for\n>>> discussion.\n>>\n>>I for one think this makes the command name dependent on a non-essential\n>>implementation detail, so -script should go.\n> \n> \n> I had the same opinion. The counter-argument people raised when\n> this topic came up on the list was that it would help grepping\n> in the source tree.\n> \n> I'm tempted to suggest doing something along these lines:\n> \n> - Rename things that are implemented in shell from *-script to\n> *.sh, and perl to *.perl in the source tree;\n\n*.pl is what is usually used for perl scripts.\n\n> \n> - Install them without .{sh,perl} suffix.\n> \n> Once this is done, the users nor the 'git' wrapper do not have\n> to deal with *-script.\n> \n> Comments?\n> \n> \n> -\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n\n\n-- \nPeter Williams pwil3058@bigpond.net.au\n\n\"Learning, n. The kind of ignorance distinguishing the studious.\"\n -- Ambrose Bierce\n"},{"id":"8068","messageId":"7vbr38bbcm.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"431B90B9.4000108@bigpond.net.au","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-05T00:35:21Z","receivedAt":"2005-09-05T00:35:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Peter Williams writes:\n\n> *.pl is what is usually used for perl scripts.\n\nMy recollection may be faulty, but '*.pl' was meant to be used\nfor older Perl libraries back in perl4 days, and the standalone\nscripts are to be named '*.perl' but many people made the\nmistake of naming them '*.pl'.\n"},{"id":"8069","messageId":"431B9521.1010703@bigpond.net.au","threadId":"1386","inReplyTo":"7vbr38bbcm.fsf@assigned-by-dhcp.cox.net","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Peter Williams","fromEmail":"pwil3058@bigpond.net.au","sentAt":"2005-09-05T00:45:21Z","receivedAt":"2005-09-05T00:45:21Z","isPatch":false,"sender":{"key":"pwil3058@bigpond.net.au","avatar":"https://gravatar.com/avatar/fc711ad9d9890c01c6ede5a99a62a8b8ca82a3eef0def8ef98e0ec7da7f99367?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Peter Williams writes:\n> \n> \n>>*.pl is what is usually used for perl scripts.\n> \n> \n> My recollection may be faulty, but '*.pl' was meant to be used\n> for older Perl libraries back in perl4 days, and the standalone\n> scripts are to be named '*.perl' but many people made the\n> mistake of naming them '*.pl'.\n\nI'm no expert and was just reporting what I'd observed but that \nobservation wasn't thorough enough to notice the distinction that you \nmake so forget what I said. :-)\n\nPeter\n-- \nPeter Williams pwil3058@bigpond.net.au\n\n\"Learning, n. The kind of ignorance distinguishing the studious.\"\n -- Ambrose Bierce\n"},{"id":"8070","messageId":"200509050054.j850sC3D023778@laptop11.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-09-05T00:54:12Z","receivedAt":"2005-09-05T00:54:12Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> Horst von Brand writes:\n> >> 3. Non-binaries are called '*-scripts'.\n> >> \n> >> In earlier discussions some people seem to like the\n> >> distinction between *-script and others; I did not\n> >> particularly like it, but I am throwing this in for\n> >> discussion.\n\n> > I for one think this makes the command name dependent on a non-essential\n> > implementation detail, so -script should go.\n\n> I had the same opinion. The counter-argument people raised when\n> this topic came up on the list was that it would help grepping\n> in the source tree.\n\nGrepping for what?\n\nIt is not /that/ much more expensive to run file(1) over the tree if you\nwant to know what is a script and what isn't. Furthermore, the \"-script\"\nextension doesn't work for this as of today (see your own message a while\nback ;-). Keeping it requires discipline that tools don't help enforcing\ntoday (and the extension use itself is very un-Unix-like), so further\n\"mistakes\" /will/ happen.\n\nIn any case, this would be for a very specialized, developer-only,\noccasional task. I don't see how that warrants a fractured tool namespace\nfor /all/ users /all/ the time.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"8071","messageId":"7vwtlw9tzo.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"200509050054.j850sC3D023778@laptop11.inf.utfsm.cl","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-05T01:35:39Z","receivedAt":"2005-09-05T01:35:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Horst von Brand writes:\n\n> Junio C Hamano wrote:\n>> I had the same opinion. The counter-argument people raised when\n>> this topic came up on the list was that it would help grepping\n>> in the source tree.\n>\n> Grepping for what?\n\nI am only a messenger for their argument and, as I said, I did\nnot particularly buy that argument because I myself do not find\nit too disturbing that a grep in my built tree says \"Binary file\nlibgit.a matches\", especially I typically run grep in my Emacs\nbuffer and C-x ` (next-error) does not get confused by such\nuseless hits. But I can understand why it matters to people\nworking in other environments.\n\n> In any case, this would be for a very specialized,\n> developer-only, occasional task. I don't see how that warrants\n> a fractured tool namespace for /all/ users /all/ the time.\n\nYes, you convinced the convert again.\n\nNow I have to find a poor unsuspecting volunteer to do the\nactual heavylifting after 0.99.6 happens ;-).\n"},{"id":"8087","messageId":"Pine.LNX.4.58.0509050738340.3504@evo.osdl.org","threadId":"1386","inReplyTo":"200509050054.j850sC3D023778@laptop11.inf.utfsm.cl","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-05T14:41:30Z","receivedAt":"2005-09-05T14:41:30Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 4 Sep 2005, Horst von Brand wrote:\n> > I had the same opinion. The counter-argument people raised when\n> > this topic came up on the list was that it would help grepping\n> > in the source tree.\n> \n> Grepping for what?\n\nGrepping for strings.\n\nFor example, when renaming a binary, the sane way to check that you fixed \nall users right now is\n\n\tgrep old-binary-name *.c *.h *-scripts\n\nand you catch all users.\n\nIn contrast, \"grep *\" will catch totally uninteresting patterns like \nobject files etc.\n\nI personally find that very useful, and I don't see _any_ point to naming \nby what _kind_ of interpreter you use. Why would _anybody_ care whether \nsomething is written in perl vs shell? There's no reason to name things by \nthe interpreter.\n\n\t\tKubys\n"},{"id":"8090","messageId":"u5tvf1feedt.fsf@lysator.liu.se","threadId":"1386","inReplyTo":"Pine.LNX.4.58.0509050738340.3504@evo.osdl.org","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2005-09-05T15:13:50Z","receivedAt":"2005-09-05T15:13:50Z","isPatch":false,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"Linus Torvalds writes:\n\n> On Sun, 4 Sep 2005, Horst von Brand wrote:\n>> > I had the same opinion. The counter-argument people raised when\n>> > this topic came up on the list was that it would help grepping\n>> > in the source tree.\n>> \n>> Grepping for what?\n>\n> Grepping for strings.\n>\n> For example, when renaming a binary, the sane way to check that you fixed \n> all users right now is\n>\n> \tgrep old-binary-name *.c *.h *-scripts\n>\n> and you catch all users.\n>\n> In contrast, \"grep *\" will catch totally uninteresting patterns like \n> object files etc.\n>\n> I personally find that very useful, and I don't see _any_ point to naming \n> by what _kind_ of interpreter you use. Why would _anybody_ care whether \n> something is written in perl vs shell? There's no reason to name things by \n> the interpreter.\n\nBut to the users (like myself), there's no point in naming it by\nwhether it's a script or a binary. Since, as a user, I couldn't care\nless that git-foobar is a shell script, I don't want to pollute the\ncommand name space with \"-script\" suffixes. Calling the command\ngit-foobar makes much more sense, and allows us to reimplement the\nscripts as binaries, or whatever.\n\nSo your argument that it makes it easier for git developers to work\nwith the source doesn't help the user.\n\nThe consequence is maybe that the scripts should be called *-script in\nthe source, but be installed without the suffix?\n\n-- \nDavid Kågedal\n"},{"id":"8095","messageId":"Pine.LNX.4.58.0509050902070.3568@evo.osdl.org","threadId":"1386","inReplyTo":"u5tvf1feedt.fsf@lysator.liu.se","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-05T16:04:18Z","receivedAt":"2005-09-05T16:04:18Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 5 Sep 2005, David Kågedal wrote:\n> \n> But to the users (like myself), there's no point in naming it by\n> whether it's a script or a binary. \n\nSo? There's no downside.\n\nTo you, as a user, you never see the \"-script\" ending anyway. You'd never \ntype it out, or you're already doing something wrong.\n\nSo to users it doesn't matter, and to developers it _does_ matter (and \ncalling them \".pl\" or \".sh\" or something would be _bad_), why not please \nthe developers?\n\n> So your argument that it makes it easier for git developers to work\n> with the source doesn't help the user.\n\nIt doesn't _help_ the user, but since it doesn't hurt him either, why the \nhell would we even _care_ about the user?\n\n\t\tLinus\n"},{"id":"8096","messageId":"u5tk6hveawy.fsf@lysator.liu.se","threadId":"1386","inReplyTo":"Pine.LNX.4.58.0509050902070.3568@evo.osdl.org","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2005-09-05T16:28:45Z","receivedAt":"2005-09-05T16:28:45Z","isPatch":false,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"Linus Torvalds writes:\n\n> On Mon, 5 Sep 2005, David Kågedal wrote:\n>> \n>> But to the users (like myself), there's no point in naming it by\n>> whether it's a script or a binary. \n>\n> So? There's no downside.\n>\n> To you, as a user, you never see the \"-script\" ending anyway. You'd never \n> type it out, or you're already doing something wrong.\n\nThen I'm doing something wrong. And I'm pretty sure others are\ntoo. If I'm not supposed to see the \"-script\" ending, then don't\ninstall it in my $PATH.\n\nUntil someone (possibly myself) writes some zsh completion code to\nhandle git sub command, I will continue to hit TAB and see all those\nnames.\n\nFurthermore, the man page for \"git clone\" is called\n\"git-clone-script(1)\". And the \"-script\" suffix appears inside the\ndocumentation in various places. I see it in howtos and log messages.\nAnd the git-merge-one-file-script script is supposed to be used in a\nway where I have to supply the long name. Etc.\n\nIf the \"-script\" part is supposed to be hidden from me, why do I keep\nseeing it everywhere I turn?\n\n> So to users it doesn't matter, and to developers it _does_ matter (and \n> calling them \".pl\" or \".sh\" or something would be _bad_), why not please \n> the developers?\n\nI'm not suggesting we'd call them \".pl\" or \".sh\".\n\n-- \nDavid Kågedal\n"},{"id":"8100","messageId":"7vr7c35qoe.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"Pine.LNX.4.58.0509050738340.3504@evo.osdl.org","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-05T18:13:05Z","receivedAt":"2005-09-05T18:13:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> ... and I don't see _any_ point to naming \n> by what _kind_ of interpreter you use. Why would _anybody_ care whether \n> something is written in perl vs shell?\n\nOne possibility that comes to mind is to again help developers\nwho use an editor that is syntax-aware and looks *only* at\nfilename suffix to figure out which language syntax to use\n(Emacs is not one of them -- it knows how to read #! line).\n\nAnother is, although we do not currently do it, to make the\nMakefile simpler if/when we start to do the interpreter line\nmunging (\"#!/usr/bin/perl -> #!/usr/local/bin/perl\") before\ninstall time.\n"},{"id":"8101","messageId":"7vek835q79.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"u5tk6hveawy.fsf@lysator.liu.se","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-05T18:23:22Z","receivedAt":"2005-09-05T18:23:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Kågedal writes:\n\n> If the \"-script\" part is supposed to be hidden from me, why do I keep\n> seeing it everywhere I turn?\n>\n>> So to users it doesn't matter, and to developers it _does_ matter (and \n>> calling them \".pl\" or \".sh\" or something would be _bad_), why not please \n>> the developers?\n>\n> I'm not suggesting we'd call them \".pl\" or \".sh\".\n\nWell, I was. Here is what I had in mind.\n\n1. Introduce SCRIPT_SH and SCRIPT_PERL, and make\n \"SCRIPTS = $(SCRIPT_SH) $(SCRIPT_PERL)\" in the Makefile.\n2. Install git-foo.sh as $(DEST)$(bin)/git-foo\n3. Documentation to describe git-foo command is Documentation/git-foo.txt\n\nI was planning to leave gitk source as gitk, not gitk.tcl nor\ngitk.wish nor gitk.sh for now, if only to help me merging from\npaurus.\n\nDepending on how people would react to the \"why would people\ncare what scripting language is the thing written in\" comment by\nLinus, I may be persuaded otherwise though, in which case 1. is\nnot needed, and 2. would lose '.sh', but 3. would not change.\n \n"},{"id":"8115","messageId":"46a038f90509051713389c62c8@mail.gmail.com","threadId":"1386","inReplyTo":"Pine.LNX.4.58.0509050738340.3504@evo.osdl.org","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-09-06T00:13:29Z","receivedAt":"2005-09-06T00:13:29Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 9/6/05, Linus Torvalds wrote:\n> Grepping for strings.\n> \n> For example, when renaming a binary, the sane way to check that you fixed\n> all users right now is\n> \n> grep old-binary-name *.c *.h *-scripts\n> \n> and you catch all users.\n\nGrep knows how to ignore binary files. Try:\n\n grep -I git-commit *\n\ncheers,\n\n\nmartin\n"},{"id":"8118","messageId":"Pine.LNX.4.58.0509060013520.4316@evo.osdl.org","threadId":"1386","inReplyTo":"46a038f90509051713389c62c8@mail.gmail.com","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-06T07:16:57Z","receivedAt":"2005-09-06T07:16:57Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 6 Sep 2005, Martin Langhoff wrote:\n> \n> Grep knows how to ignore binary files.\n\nThat wasn't the _point_.\n\nThe point is, naming things as being \"scripts\" is useful. Grep is just an \nexample. Naming things as being \".pl\" or \".sh\" is _not_ useful.\n\nSo with grep you can use -I, but what about doing things like \"em *\" when\ndoing global renames (I use micro-emacs - em - as my editor). Again, \"em\n*-script\" actually works.\n\nThe point being that if we have naming rules, make them USEFUL. *-script \nis useful - it works wonderfully well for \"git xxx\" (which knows to add \n\"-script\"), and it works wonderfully well for developers. \n\n\t\tLinus\n"},{"id":"8119","messageId":"7vll2atz8a.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"Pine.LNX.4.58.0509060013520.4316@evo.osdl.org","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-06T07:46:45Z","receivedAt":"2005-09-06T07:46:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> The point is, naming things as being \"scripts\" is useful. Grep is just an \n> example. Naming things as being \".pl\" or \".sh\" is _not_ useful.\n\nSorry, but why not?\n"},{"id":"8120","messageId":"46a038f90509060053cdd57e1@mail.gmail.com","threadId":"1386","inReplyTo":"Pine.LNX.4.58.0509060013520.4316@evo.osdl.org","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2005-09-06T07:53:15Z","receivedAt":"2005-09-06T07:53:15Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 9/6/05, Linus Torvalds wrote:\n> That wasn't the _point_.\n\nAgreed - sorry I should have qualified my comment.\n\nI agree with having useful extensions for ease of development. And I\nagree with the suggestion of installing them with stripped extensions\n-- to extend the abstraction.\n\nOTOH...\n> The point is, naming things as being \"scripts\" is useful. Grep is just an\n> example. Naming things as being \".pl\" or \".sh\" is _not_ useful.\n\nHrmmm. Not so convinced about that. There are good reasons to\ndistinguish files with different internal syntax. Perhaps it's your\nC-bias but for script maintainers it isn't helpful to deal with\n-script prefixes.\n\nIf a bash script is rewritten in C, it is a useful and meaningful\nchange (from a developer perspective) that the file changes name. Both\ncan live in the tree while the new one matures, running diffs or\npickaxes will show one file created and another removed, instead of a\nvery meaningless diff. The same applies if it is rewritten in Perl, or\nPython.\n\nIOW: Perl programmers are developers too ;-)\n\ncheers,\n\n\nmartin\n"},{"id":"8121","messageId":"Pine.LNX.4.58.0509060057491.4316@evo.osdl.org","threadId":"1386","inReplyTo":"7vll2atz8a.fsf@assigned-by-dhcp.cox.net","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-06T07:59:04Z","receivedAt":"2005-09-06T07:59:04Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 6 Sep 2005, Junio C Hamano wrote:\n\n> Linus Torvalds writes:\n> \n> > The point is, naming things as being \"scripts\" is useful. Grep is just an \n> > example. Naming things as being \".pl\" or \".sh\" is _not_ useful.\n> \n> Sorry, but why not?\n\nWhat's the upside?\n\nI can point to one downside: \"git\". That script right now is simple. If \nyou rewrite git-cvsimport-script from shell to perl, it looks the same to \ngit. \n\n\t\tLinus\n"},{"id":"8122","messageId":"7vwtlusi9t.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"Pine.LNX.4.58.0509060057491.4316@evo.osdl.org","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-06T08:38:22Z","receivedAt":"2005-09-06T08:38:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> What's the upside?\n>\n> I can point to one downside: \"git\". That script right now is simple. If \n> you rewrite git-cvsimport-script from shell to perl, it looks the same to \n> git. \n\nWhat I've been working on was to:\n\n * have git-cvsimport.perl in the source\n\n * install it as $(bindir)/git-cvsimport\n\n * simplify 'git' (whose source is of course in 'git.sh') to\n only do: \n\n cmd=\"$1\"; shift; exec \"git-$cmd\" ${1+\"$@\"}\n\nNaturally, the rewrite of git-cvsimport in shell or C would look\nthe same to git.\n\nOne potential downside (for people who consider this a downside)\nis that you cannot easily run uninstalled, but you already\ncannot run tools/git-applymbox and git-cherry-pick uninstalled\nanyway, and I do not think it is such a big deal.\n"},{"id":"8123","messageId":"u5tek82bmlb.fsf@fidgit.hq.vtech","threadId":"1386","inReplyTo":"7vwtlusi9t.fsf@assigned-by-dhcp.cox.net","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"David Kågedal","fromEmail":"davidk@lysator.liu.se","sentAt":"2005-09-06T08:57:04Z","receivedAt":"2005-09-06T08:57:04Z","isPatch":false,"sender":{"key":"davidk@lysator.liu.se","avatar":"https://avatars.githubusercontent.com/u/60530?v=4"},"body":"Junio C Hamano writes:\n\n> Linus Torvalds writes:\n>\n>> What's the upside?\n>>\n>> I can point to one downside: \"git\". That script right now is simple. If \n>> you rewrite git-cvsimport-script from shell to perl, it looks the same to \n>> git. \n>\n> What I've been working on was to:\n>\n> * have git-cvsimport.perl in the source\n>\n> * install it as $(bindir)/git-cvsimport\n\nThat was what I suggested too, although I don't really care if it's\ncalled .perl or -script in the source.\n\nBy the way, I'm not sure how the 'git' script is supposed to be used.\nI know that if there is a git-foo-script file in your path, you can\nrun it as 'git foo'. But what about e.g. git-init-db? You can run\nthat as 'git init-db' today. And 'git read-cache' should work too.\nAnd 'git ls-files', and 'git rev-parse', and 'git merge-one-file' and\n'git sh-setup-script' in decreasing order of usefulness...\n\nBut running 'git' without arguments only list the -script commands as\navailable.\n\n-- \nDavid Kågedal\n"},{"id":"8128","messageId":"431DC6D9.30802@progeny.com","threadId":"1386","inReplyTo":"200509020150.j821oXXM006699@laptop11.inf.utfsm.cl","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Tim Ottinger","fromEmail":"tottinge@progeny.com","sentAt":"2005-09-06T16:42:01Z","receivedAt":"2005-09-06T16:42:01Z","isPatch":false,"sender":{"key":"tottinge@progeny.com","avatar":null},"body":"Horst von Brand wrote:\n\n>Junio C Hamano wrote:\n> \n>\n>>Tim Ottinger writes:\n>> \n>>\n>>>git-update-cache for instance?\n>>>I am not sure which 'cache' commands need to be 'index' now.\n>>> \n>>>\n>>Logically you are right, but I suspect that may not fly well in practice. Too many of us have already got our fingers wired to type cache, and the glossary is there to describe both cache andindex.\n>> \n>>\n>\n>I'd vote for cleaning it up /now/. Sure, it will hurt, but if you let time\n>go by and do it later, it will hurt much more.\n>\n>Pre-1.0 is the last chance, AFAICS.\n> \n>\nI guess it all depends on whether your target audience is already using\nit an happy with how it is, or whether your target audience is yet to\nbe reached.\n\nIs git growing? Do we expect to suddenly find git upside down, where\nthere are a few old-timers awash in a sea of newbies? Do we care?\n\nIf you care, and git is growing, then probably it makes sense to\nchoose \"the greatest good for the greatest number\", I guess.\n\nPersonally, I'm a newbie and I find the command set confusing and\nhard to internalize for reasons mostly dealing with naming, but also\nbecause I don't have 6 months shared history with all of you. I have\nto learn it partly from docs and partly through folklore gleaned from\nthe list (which moves pretty quickly).\n\nMaybe that's just complaining, but maybe it is pointing out a\nweakness that's correctable.\n\n-- \n ><>\n... either 'way ahead of the game, or 'way out in left field.\n"},{"id":"8153","messageId":"7v1x41g3c6.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"u5tek82bmlb.fsf@fidgit.hq.vtech","subject":"Re: Tool renames? was Re: First stab at glossary","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-06T23:54:01Z","receivedAt":"2005-09-06T23:54:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"> By the way, I'm not sure how the 'git' script is supposed to be used.\n> I know that if there is a git-foo-script file in your path, you can\n> run it as 'git foo'. But what about e.g. git-init-db? You can run\n> that as 'git init-db' today. And 'git read-cache' should work too.\n> And 'git ls-files', and 'git rev-parse', and 'git merge-one-file' and\n> 'git sh-setup-script' in decreasing order of usefulness...\n>\n> But running 'git' without arguments only list the -script commands as\n> available.\n\nYou are correct. I think 'git' showing only *-script was done\nas an attempt to give a list of Porcelainish commands, excluding\nthe core commands that people are not supposed to be typing from\nthe command line. It so happened that all of the Porcelainish\ncommands were scripts.\n\nBut what Linus wants *-script to mean is editability in the\nsource tree (his \"grep\" and \"em\" examples). The command being\nPorcelainish and the command being implemented as a script tend\nto have strong correlations, but in principle they are\northogonal. As you mention, 'git merge-one-file' is not really\nuseful standalone, neither is 'git sh-setup'. On the other\nhand, 'git fsck-cache' is.\n\nMy proposal to have git-archimport.perl in the source tree and\ninstall it as $(bindir)/git-archimport solves the editability\nissues (sorry, Linus, you will have to say \"em *.sh *.perl\"\ninstead of \"em *-script\" if we did this) and simplifies the\nfirst half of the 'git' wrapper (it just needs to attempt\nrunning \"git-$1\"), but does not help what the latter half of\n'git' wrapper does (to give you the list of Porcelainish\ncommands).\n\nTo make 'git' wrapper produce useful 'list of subcommands', we\nneed to come up with a list of Porcelainish commands, be they\nwritten in C or sh or Perl, and tell 'git' about that list.\nCurrent implementation cheats by assuming everything that ends\nwith *-script are such, but it does not have to stay that way.\n\nI'd nominate all $(SCRIPTS) in Makefile and tools/Makefile\nexcept *1*, plus *2* as the list of subcommands 'git' wrapper\nwould show.\n\nList *1*: implemented as script but not Porcelainish.\n\tgit\n git-merge-one-file-script\n git-sh-setup-script\n\nList *2*: implemented in C but Porcelainish.\n\tgit-init-db\n git-fsck-cache\n git-get-tar-commit-id\n git-apply\n git-patch-id\n git-pack-objects\n git-show-branch\n"},{"id":"8179","messageId":"7vfysg2wvo.fsf_-_@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"7v1x41g3c6.fsf@assigned-by-dhcp.cox.net","subject":"Tool renames.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-08T01:04:11Z","receivedAt":"2005-09-08T01:04:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> My proposal to have git-archimport.perl in the source tree and\n> install it as $(bindir)/git-archimport solves the editability\n> issues (sorry, Linus, you will have to say \"em *.sh *.perl\"\n> instead of \"em *-script\" if we did this) and simplifies the\n> first half of the 'git' wrapper (it just needs to attempt\n> running \"git-$1\"), but does not help what the latter half of\n> 'git' wrapper does (to give you the list of Porcelainish\n> commands).\n>\n> To make 'git' wrapper produce useful 'list of subcommands', we\n> need to come up with a list of Porcelainish commands, be they\n> written in C or sh or Perl, and tell 'git' about that list.\n> Current implementation cheats by assuming everything that ends\n> with *-script are such, but it does not have to stay that way.\n\nI have done this and the first commit since 0.99.6 in the\nproposed updates branch contains the big rename.\n"},{"id":"8469","messageId":"200509131739.j8DHdQL1010615@laptop11.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: [PATCH] Improve \"git grep\" flags handling","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-09-13T17:39:26Z","receivedAt":"2005-09-13T17:39:26Z","isPatch":true,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n\n[...]\n\n> Thanks, Linus. This is what will go into \"master\" tonight.\n> \n> git-grep.sh | 64 ++++++++++++++++++++++++++++++++++++++---------------------\n> 1 files changed, 41 insertions(+), 23 deletions(-)\n> \n> 6df4eef9b10c8de2b9bc3dc769f3a008a1200df7\n> diff --git a/git-grep.sh b/git-grep.sh\n> --- a/git-grep.sh\n> +++ b/git-grep.sh\n> @@ -1,25 +1,43 @@\n> #!/bin/sh\n\nShouldn't shebang go /bin/bash, as the script uses bash-isms now?\n(For portability to non-enlightened systems the installation would have to\nlocate bash too... and/or mention this in the INSTALL file)\n\nOr perhaps redo the mess in Perl or some such?\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"8471","messageId":"Pine.LNX.4.58.0509131044340.3351@g5.osdl.org","threadId":"1386","inReplyTo":"200509131739.j8DHdQL1010615@laptop11.inf.utfsm.cl","subject":"Re: [PATCH] Improve \"git grep\" flags handling","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-13T17:51:23Z","receivedAt":"2005-09-13T17:51:23Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 13 Sep 2005, Horst von Brand wrote:\n> \n> Shouldn't shebang go /bin/bash, as the script uses bash-isms now?\n> (For portability to non-enlightened systems the installation would have to\n> locate bash too... and/or mention this in the INSTALL file)\n\nSome bash installs only install in /bin/sh, so..\n\n> Or perhaps redo the mess in Perl or some such?\n\nHey, the code isn't a mess. The fact that there are tons of different \nshells and they don't support it is the mess.\n\nSo we should strive for bash syntax to be so common that other shells \nfollow suit ;)\n\nI personally find perl to be a really bad language. It has more of a \nunified base (different versions, but at least not totally different and \nunrelated implementations), and it's clearly more powerful, but as a \n_language_ I don't understand how anybody can accept that crap.\n\nThe \"there's more than one way to do something\" slogan may be cute and\nsound good to people who are drawn to that thing, but it's actually bad. \nThe language is designed to be write-only, and the \"you can do it fifty\ndifferent ways\" is part of it (and line noise characters is another part\nof it).\n\nSo sh is actually often a much better language. Too bad some of the \nfeatures end up being outside the standard language.\n\nI know, I know, people will consider me crazy for saying that. \n\nOh, well. As long as all the _important_ stuff is in C, we're ok.\n\n\t\t\tLinus\n"},{"id":"8473","messageId":"7v8xy03ilk.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"200509131739.j8DHdQL1010615@laptop11.inf.utfsm.cl","subject":"Re: [PATCH] Improve \"git grep\" flags handling","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-13T18:53:11Z","receivedAt":"2005-09-13T18:53:11Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Horst von Brand writes:\n\n> Shouldn't shebang go /bin/bash, as the script uses bash-isms now?\n> (For portability to non-enlightened systems the installation would have to\n> locate bash too... and/or mention this in the INSTALL file)\n\nI heard somebody say the shell arrays actually came from Korn,\nso /bin/bash is a wrong thing to do if that is the case.\n\n> Or perhaps redo the mess in Perl or some such?\n\nEspecially given 'xargs grep' part is moderately expensive\nanyway and startup overhead between shell and perl does not\nmatter here very much, the suggestion is mildly tempting.\n"},{"id":"8474","messageId":"Pine.LNX.4.58.0509131203280.3351@g5.osdl.org","threadId":"1386","inReplyTo":"7v8xy03ilk.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Improve \"git grep\" flags handling","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2005-09-13T19:09:25Z","receivedAt":"2005-09-13T19:09:25Z","isPatch":true,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 13 Sep 2005, Junio C Hamano wrote:\n> \n> I heard somebody say the shell arrays actually came from Korn,\n> so /bin/bash is a wrong thing to do if that is the case.\n\nMe. \n\nThere are differences in indexing the arrays between ksh and bash, but I\nthink the git-grep.sh style of usage should work on both bash and ksh.\n\n[ goes off and tests ]\n\nIndeed. I just tested the thing I sent out with \"ksh git-grep.sh ..\" and \nit worked fine.\n\nUsing \"zsh\" the grep flags don't work, and \"tcsh\" obviously will never run\n_any_ valid shell code ;)\n\n\t\tLinus\n"},{"id":"8491","messageId":"200509132203.j8DM3foH008451@laptop11.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: dumb transports not being welcomed..","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-09-13T22:03:41Z","receivedAt":"2005-09-13T22:03:41Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n\n[...]\n\n> Using cogito is not a problem at all. The mechanism to prepare\n> trees to serve wider audience not being used widely is.\n\nIt isn't really documented...\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"8496","messageId":"7vek7swqrm.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"200509132203.j8DM3foH008451@laptop11.inf.utfsm.cl","subject":"Re: dumb transports not being welcomed..","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-13T22:23:57Z","receivedAt":"2005-09-13T22:23:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Horst von Brand writes:\n\n> Junio C Hamano wrote:\n>\n> [...]\n>\n>> Using cogito is not a problem at all. The mechanism to prepare\n>> trees to serve wider audience not being used widely is.\n>\n> It isn't really documented...\n\nTrue. The existing documentation might be sketchy. We only\nhave the following documentation pages right now. Clarification\npatches are welcome.\n\nhttp://www.kernel.org/pub/software/scm/git/docs/tutorial.html\n Look for \"Publishing your work\" section, and\n \"Working with Others section, \"project lead\" and \"subsystem\n maintainer\" subsections, both bullet point #2.\n\nhttp://www.kernel.org/pub/software/scm/git/docs/git-update-server-info.html\n The above sections in the tutorial repeatedly mentions this\n command.\n\nhttp://www.kernel.org/pub/software/scm/git/docs/repository-layout.html\n And git-update-server-info documentation refers to this page.\n Look for \"objects/info/packs\" and \"info/refs\".\n"},{"id":"8582","messageId":"43290D0F.9060408@zytor.com","threadId":"1386","inReplyTo":"7vfysg2wvo.fsf_-_@assigned-by-dhcp.cox.net","subject":"Re: Tool renames.","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-09-15T05:56:31Z","receivedAt":"2005-09-15T05:56:31Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \n> I have done this and the first commit since 0.99.6 in the\n> proposed updates branch contains the big rename.\n> \n\nI noticed you also renamed git-ssh-{push,pull}. These tools rely on \nhaving the same names on both sides, so you have introduced a major \nversion skew problem.\n\n\t-hpa\n"},{"id":"8589","messageId":"7vr7bqahb8.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"43290D0F.9060408@zytor.com","subject":"Re: Tool renames.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-15T08:03:39Z","receivedAt":"2005-09-15T08:03:39Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" writes:\n\n> I noticed you also renamed git-ssh-{push,pull}. These tools rely on \n> having the same names on both sides, so you have introduced a major \n> version skew problem.\n\nTrue. It seems that both myself and Daniel did not think that\nwould be a major problem when we were discussing the tool\nrenames.\n\nAs a workaround, you could always say GIT_SSH_PULL='blah' and\nGIT_SSH_PUSH='bah' when you run either side to name what will be\nrun on the other end.\n\nNow the interesting problem is if we should rename these\nenvironment variables ...\n"},{"id":"8593","messageId":"7vr7bq4ssc.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"7vr7bqahb8.fsf@assigned-by-dhcp.cox.net","subject":"Re: Tool renames.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-15T08:52:19Z","receivedAt":"2005-09-15T08:52:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> \"H. Peter Anvin\" writes:\n>\n>> I noticed you also renamed git-ssh-{push,pull}. These tools rely on \n>> having the same names on both sides, so you have introduced a major \n>> version skew problem.\n>\n> True. It seems that both myself and Daniel did not think that\n> would be a major problem when we were discussing the tool\n> renames.\n>\n> As a workaround, you could always say GIT_SSH_PULL='blah' and\n> GIT_SSH_PUSH='bah' when you run either side to name what will be\n> run on the other end.\n\nCome to think of it, I should be able to build git-ssh-push and\ngit-ssh-pull as fully backward compatible way to call the\ncounterpart with original name, instead of supplying just\nsymlinks the same way I do currently. Let me work do that\nbefore I do 0.99.7 this weekend.\n\n> Now the interesting problem is if we should rename these\n> environment variables ...\n\nAnd the old and new binaries will be built separately anyway, I\ncould use GIT_SSH_FETCH and GIT_SSH_UPLOAD in the newname\nbinaries while keeping the old names in oldname binaries. Ack?\n"},{"id":"8655","messageId":"432A5BCE.3030200@zytor.com","threadId":"1386","inReplyTo":"7vr7bq4ssc.fsf@assigned-by-dhcp.cox.net","subject":"Re: Tool renames.","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-09-16T05:44:46Z","receivedAt":"2005-09-16T05:44:46Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Junio C Hamano wrote:\n> \n> Come to think of it, I should be able to build git-ssh-push and\n> git-ssh-pull as fully backward compatible way to call the\n> counterpart with original name, instead of supplying just\n> symlinks the same way I do currently. Let me work do that\n> before I do 0.99.7 this weekend.\n> \n\nBetter yet, always install the links, and have them use the *old* names \nwhen calling the remote end.\n\n>>Now the interesting problem is if we should rename these\n>>environment variables ...\n> \n> And the old and new binaries will be built separately anyway, I\n> could use GIT_SSH_FETCH and GIT_SSH_UPLOAD in the newname\n> binaries while keeping the old names in oldname binaries. Ack?\n\nUrk. Why do this rename anyway?\n\nTypically when doing new environment variables like this you do:\n\n\tfoo = getenv(\"NEW_NAME\");\n\tif ( !foo )\n\t\tfoo = getenv(\"OLD_NAME\");\n\n\t-hpa\n"},{"id":"8659","messageId":"7vk6hhsfcy.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"432A5BCE.3030200@zytor.com","subject":"Re: Tool renames.","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-09-16T06:20:45Z","receivedAt":"2005-09-16T06:20:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"H. Peter Anvin\" writes:\n\n> Urk. Why do this rename anyway?\n\nThe \"big rename\"? Or these two environment variables?\n\nThe former is because it was brought up by somebody who was\nintroduced to git not so long time ago (i.e. fingers not so\ntrained to use the old names and the brain wired to terminology\nfound in the glossary document) for consistency, with favorable\nresponse from the git list. The latter is just me feeling that\nwould make things more consistent.\n\nAs I outlined, if you keep using the git-ssh-{push,pull} names,\nnothing should break. They call each other using old names, and\n0.99.7 will ship both new and old, so one end having 0.99.5 and\nthe other having 0.99.7 should not be a problem both ways. The\nsame goes for those GIT_SSH_* environment variables -- backward\ncompatible commands honor environment variables with old names.\n\n> Typically when doing new environment variables like this you do:\n\nYes that was what we did with the other old environment names,\nbut I can finally deprecate them in 0.99.7.\n\nInitially I said 0.99.8 will stop supporting the old names\n(including git-ssh-{push,pull}) and switch to new names only,\nbut I could be talked into carrying that beyond that, although I\nhave not heard any objections for that \"dropping\" plan since I\ninitially announced it when 0.99.6 was done.\n\nBut I personally prefer dropping the old names before we hit 1.0.\n"},{"id":"8769","messageId":"200509170158.j8H1wOVh027636@inti.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: deprecating more","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-09-17T01:58:24Z","receivedAt":"2005-09-17T01:58:24Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n\n[About axing programs]\n\n> Among them, I could be talked into keeping git-export on the\n> condition that we will add a counterpart git-import that can\n> read git-export output and recreate an identical repository\n> [*1*]; without something like that, I doubt its usefulness,\n> especially since \"git-whatchanged\" is far more useful for\n> everyday use.\n> \n> [Footnote]\n> \n> *1* which I think actually is impossible without fixing\n> git-export first so that it exports the initial commit. I may\n> be mistaken.\n\nGiven that you can just tar the whole repository up and handle it that way,\nall that work makes little sense.\n\nNote that bk export (and cg-export) copy the current snapshot into a\ndirectory or tarball, so this doesn't do what I'd expected.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"8957","messageId":"200509200312.j8K3C2KZ002935@inti.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: What shall we do with the GECOS field again?","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-09-20T03:12:02Z","receivedAt":"2005-09-20T03:12:02Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> Linus Torvalds writes:\n> > The Perl User::pwent module seems to agree, btw (also about '&'):\n> >\n> > \"Interpretation of the gecos field varies between systems, but\n> > traditionally holds 4 comma-separated fields containing the user's\n> > full name, office location, work phone number, and home phone number. \n> >\n> > An & in the gecos field should be replaced by the user's properly\n> > capitalized login name.\"\n> \n> I vaguelly recall seeing that & somewhere and wondering what\n> they do with mcdonalds ;-)\n\nYou can't use it in that case.\n\n> > I still worry about names of the type \"Torvalds, Linus\", but maybe that's \n> > just not an issue.\n> \n> Does not appear to be. So I'd vote for us doing the \"cut at\n> first comma, substitute & with toupper(login[0])+login[1..]\".\n\nThat is exactly the intent.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"9629","messageId":"200510031509.j93F97Ij018270@laptop11.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: What to expect after 0.99.8","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-10-03T15:09:07Z","receivedAt":"2005-10-03T15:09:07Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> A Large Angry SCM writes:\n> \n> > If you were to publish the ToDo to the mailing list once a week it might \n> > encourage more of those patches you want to accept.\n> \n> Hmph. I tend to dislike periodical posting that is more often\n> than once a month.\n> \n> >> * Accept patches to finish missing docs.\n> >\n> > A list of missing, incomplete, and/or wrong docs in the ToDo file would \n> > help focus effort when people (like me) have space cycles.\n\n> Well, the thing is, I am not good at documentation, especially\n> when I have other interests, and once I start writing a list of\n> missing or incomplete docs, my interests _will_ shift to fill in\n> those gaps and I will end up doing them myself, which means I\n> would not have a chance to place the list in the TODO file.\n\nThen put the following on the TODO list:\n\n* Accept patches to the TODO list for missing/incomplete/... documentation\n\n;-)\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"9680","messageId":"200510041952.j94Jq1Hs016453@laptop11.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: [PATCH] Return error when not checking out an entry due to dirtiness.","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-10-04T19:52:01Z","receivedAt":"2005-10-04T19:52:01Z","isPatch":true,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> Without -f flag, 'git-checkout-index foo.c' issued an error message\n> when foo.c already existed in the working tree and did not match index.\n> However it did not return an error from the underlying checkout_entry()\n> function and resulted in a successful exit(0).\n> \n> Signed-off-by: Junio C Hamano \n> \n> ---\n> \n> * I've made sure that the existing scripts do not use\n> checkout-index without -f in a way that could be affected by\n> this change. However, third-party scripts may be affected by\n> this. Cogito and StGIT should be OK -- they either run\n> checkout with -f, do not check the error return when it does\n> not use -f, or runs checkout without -f in an empty working\n> tree.\n> \n> checkout-index.c | 11 ++++++++---\n> entry.c | 2 +-\n> 2 files changed, 9 insertions(+), 4 deletions(-)\n> \n> 5a166f6a9d1b7ca2de673139fbfc4112b1b2e308\n> diff --git a/checkout-index.c b/checkout-index.c\n> --- a/checkout-index.c\n> +++ b/checkout-index.c\n> @@ -63,15 +63,20 @@ static int checkout_file(const char *nam\n> \n> static int checkout_all(void)\n> {\n> -\tint i;\n> +\tint i, errs;\n> \n> -\tfor (i = 0; i < active_nr ; i++) {\n> +\tfor (errs = i = 0; i < active_nr ; i++) {\n\nThis is ugly. Why not just:\n\n errs = 0;\n for (i = 0; i < active_nr ; i++) { \n\n(errs is in no way the variable controlled by the for).\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"10720","messageId":"200510272113.j9RLD5ho017717@laptop11.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: [TENTATIVE PATCH] Complain loudly, dying, when a ref is invalid","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-10-27T21:13:05Z","receivedAt":"2005-10-27T21:13:05Z","isPatch":true,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n\n[...]\n\n> Not that the current loop is any better for that purpose. We\n> silently ignore not just dangling ref and ref not storing\n> 40-byte hex, but files starting with a period '.', names longer\n> than 255 bytes, and unreadable ones, all of which we would\n> probably want to warn about in such a tool.\n\nI have yet to come across a filesystem allowing names of more than 255\ncharacters... \n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"10987","messageId":"200510312141.j9VLemi9003820@inti.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Archaeology [Was: Re: GIT 0.99.9]","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-10-31T21:40:48Z","receivedAt":"2005-10-31T21:40:48Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n\n[...]\n\n> One good thing to have would be to add a section to Tutorial.\n> Currently we cover building a small project from scratch and\n> have the readers graduate when they learn basic commit swapping,\n> but we do not talk much about archaeology tools.\n\nOne of the problems with that is to have a sufficiently rich repository at\nhand. People who futz around with git could be directed to get the latest\ngit from git for a guided tour.\n\nOr create a script like the one in the cogito tutorial to build up someting\ninteresting and then direct people to look it over.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"10985","messageId":"200511012315.jA1NFHbH003838@inti.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-11-01T23:15:17Z","receivedAt":"2005-11-01T23:15:17Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n\n[...]\n\n> I do not know much about how things are done in the RPM world,\n> but is there a concept of \"the upstream\" vs \"packaging\n> maintainer\" there? IOW, are the majority of RPM binary packages\n> done by the upstream maintainer?\n\nNo, they aren't. RPM is set up so you can take the vanilla upstream package\nand add local patches, special configuration, ... at will downstream.\n> \n> I am currently generating i386 RPMs and i386 debs myself but I\n> am not particularly proud of the current setup. I do not have\n> an RPM based machine that I can install the result myself to\n> test (which is what started this thread). Since I am not a\n> Debian developer (and I do not particularly wish to become one\n> myself), the debs I generate will not be official anyway.\n> Personally I'd be happier if I can just lose rpm and deb targets\n> from the \"upstream\" Makefile (git-core.spec file and debian/\n> subdirectory as well while we are at it), ask \"packaging\n> maintainers\" to pull from kernel.org/ tree and do RPMs and Debs\n> outside.\n\nPlease keep the git-core.spec file, it is useful to be able to build RPMs\ndirectly from the tarball.\n\n[...]\n\n> One thing we could do without breaking much of the current\n> arrangement is to have a team of people to help porting for\n> major packaging formats (RPMs and Debs mostly but I know we have\n> OpenBSD and Darwin people here too), and ask them to feed me the\n> updates to rpm/deb/whatever target in the Makefile as needed.\n> Especially before a major release I could ask them to test\n> things out and generate binary packages, perhaps taken out of\n> the tip of the master branch, or even another \"for-porters\"\n> branch for this purpose.\n\nGood idea. Will build RPMs regularly then.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"10989","messageId":"7vwtjr3elp.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"200511012315.jA1NFHbH003838@inti.inf.utfsm.cl","subject":"Re: git 0.99.9: Subversion importer breaks RPM generation (rpmbuild bug)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-02T03:36:50Z","receivedAt":"2005-11-02T03:36:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Horst von Brand writes:\n\n> Junio C Hamano wrote:\n>\n>> One thing we could do without breaking much of the current\n>> arrangement is to have a team of people to help porting for\n>> major packaging formats (RPMs and Debs mostly but I know we have\n>> OpenBSD and Darwin people here too), and ask them to feed me the\n>> updates to rpm/deb/whatever target in the Makefile as needed.\n>> Especially before a major release I could ask them to test\n>> things out and generate binary packages, perhaps taken out of\n>> the tip of the master branch, or even another \"for-porters\"\n>> branch for this purpose.\n>\n> Good idea. Will build RPMs regularly then.\n\nCan I take that to mean you are volunteering?\n"},{"id":"11180","messageId":"200511060312.jA63CUcv010887@inti.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: git binary directory?","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-11-06T03:12:30Z","receivedAt":"2005-11-06T03:12:30Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> Linus Torvalds writes:\n> > Now, I happen to think that 2500+ files in /usr/bin is a bit much (ever \n> > try to use the horrid gnome executable finder on it when you want to \n> > convince firefox to use xpdf instead of that broken crap called \"evince\"? \n> > Takes absolutely ages and is horrible).\n> >\n> > And git made it about 4% worse all on its own.\n\n[...]\n\n> Since we do not have enough clout to have /usr/bin/git/ and ask\n> the users to put that in their PATH like X11 does,\n\nThat is going away. No more /usr/X11R6/{bin,lib,man} junk.\n\n> we need to\n> teach some of our commands that use other git commands to\n> prepend /usr/lib/git/ (or /usr/libexec/git)\n\nAFAIU, /usr/libexec/git (or /usr/libexec/git-) would be better.\nIncluding the version would make it possible to have the last stable and a\ndevelopment version coexisting, like gcc does with -V. Or its -B option,\nwhich tells it where to find the executables that do the real work.\n\n> on their PATH while\n> they run. Although many of the Porcelainish commands include\n> git-sh-setup, git-sh-setup itself is a prime candidate to be\n> kicked out of /usr/bin, which means essentially everything needs\n> to have that PATH trick.\n\n> This also is a bit inconvenient for our in-source-tree tests.\n\nExplicitly saying where to find all the stuff with -B would help here.\n\n\nThe only downside is that git- won't find them anymore, but I'm sure\nthe bash-completion people will fix that soon ;-)\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"11182","messageId":"20051106050049.GA5910@vrfy.org","threadId":"1386","inReplyTo":"200511060312.jA63CUcv010887@inti.inf.utfsm.cl","subject":"Re: git binary directory?","fromName":"Kay Sievers","fromEmail":"kay.sievers@vrfy.org","sentAt":"2005-11-06T05:00:49Z","receivedAt":"2005-11-06T05:00:49Z","isPatch":false,"sender":{"key":"kay.sievers@vrfy.org","avatar":null},"body":"On Sun, Nov 06, 2005 at 12:12:30AM -0300, Horst von Brand wrote:\n> Junio C Hamano wrote:\n> > Linus Torvalds writes:\n> > > Now, I happen to think that 2500+ files in /usr/bin is a bit much (ever \n> > > try to use the horrid gnome executable finder on it when you want to \n> > > convince firefox to use xpdf instead of that broken crap called \"evince\"? \n> > > Takes absolutely ages and is horrible).\n> > >\n> > > And git made it about 4% worse all on its own.\n> \n> [...]\n> \n> > Since we do not have enough clout to have /usr/bin/git/ and ask\n> > the users to put that in their PATH like X11 does,\n> \n> That is going away. No more /usr/X11R6/{bin,lib,man} junk.\n> \n> > we need to\n> > teach some of our commands that use other git commands to\n> > prepend /usr/lib/git/ (or /usr/libexec/git)\n> \n> AFAIU, /usr/libexec/git (or /usr/libexec/git-) would be better.\n\nNote that \"libexec\" is not LSB conform - whatever that means, but it\nshould probably not be used for new projects. It states: \"Applications\nmay use a single subdirectory under /usr/lib.\"\n\nKay\n"},{"id":"11184","messageId":"7v4q6q5ock.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"20051106050049.GA5910@vrfy.org","subject":"Re: git binary directory?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-06T05:36:59Z","receivedAt":"2005-11-06T05:36:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Kay Sievers writes:\n\n> Note that \"libexec\" is not LSB conform - whatever that means, but it\n> should probably not be used for new projects. It states: \"Applications\n> may use a single subdirectory under /usr/lib.\"\n\nI had an impression that there are still UNIXy systems that are\nnot even Linux; do they follow LSB and drop libexec?\n"},{"id":"11186","messageId":"20051106082338.GN1431@pasky.or.cz","threadId":"1386","inReplyTo":"7v4q6q5ock.fsf@assigned-by-dhcp.cox.net","subject":"Re: git binary directory?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-06T08:23:38Z","receivedAt":"2005-11-06T08:23:38Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Nov 06, 2005 at 06:36:59AM CET, I got a letter\nwhere Junio C Hamano told me that...\n> Kay Sievers writes:\n> \n> > Note that \"libexec\" is not LSB conform - whatever that means, but it\n> > should probably not be used for new projects. It states: \"Applications\n> > may use a single subdirectory under /usr/lib.\"\n> \n> I had an impression that there are still UNIXy systems that are\n> not even Linux; do they follow LSB and drop libexec?\n\nAt least BSDs still seem to have libexec, but they are just as likely to\nhave lib, I would say, while on Linux it is going away (not that I would\nbe excited about it). So we could either make this per-system, or\ndefault to something that is going to be present everywhere (lib),\nI think.\n\n-- \n\t\t\tPetr \"Pasky libdir=$(prefix)/lib/cogito\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11187","messageId":"20051106082830.GO1431@pasky.or.cz","threadId":"1386","inReplyTo":"200511060312.jA63CUcv010887@inti.inf.utfsm.cl","subject":"Re: git binary directory?","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2005-11-06T08:28:30Z","receivedAt":"2005-11-06T08:28:30Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Nov 06, 2005 at 04:12:30AM CET, I got a letter\nwhere Horst von Brand told me that...\n> Junio C Hamano wrote:\n> > we need to\n> > teach some of our commands that use other git commands to\n> > prepend /usr/lib/git/ (or /usr/libexec/git)\n> \n> AFAIU, /usr/libexec/git (or /usr/libexec/git-) would be better.\n> Including the version would make it possible to have the last stable and a\n> development version coexisting, like gcc does with -V. Or its -B option,\n> which tells it where to find the executables that do the real work.\n\nIn Cogito, when including the lib programs, I'm doing\n\n\t. ${COGITO_LIB}cg-Xlib || exit 1\n\nand then during installation I do:\n\n\tsed -e 's/\\$${COGITO_LIB}/\"\\$${COGITO_LIB:-$(libdir)\\/}\"/g'\n\nThen I can override it during execution by exporting $COGITO_LIB.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nVI has two modes: the one in which it beeps and the one in which\nit doesn't.\n"},{"id":"11188","messageId":"7vzmoi2n1f.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"20051106082338.GN1431@pasky.or.cz","subject":"Re: git binary directory?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2005-11-06T08:33:32Z","receivedAt":"2005-11-06T08:33:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> At least BSDs still seem to have libexec, but they are just as likely to\n> have lib, I would say, while on Linux it is going away (not that I would\n> be excited about it). So we could either make this per-system, or\n> default to something that is going to be present everywhere (lib),\n> I think.\n\nYes, that should definitely be done per system. The main\nMakefile does not have it different from bindir. In fact, the\nmain Makefile still installs everything in $HOME/bin by default.\n"},{"id":"13177","messageId":"200512042016.jB4KGEIt031938@pincoya.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: [ANNOUNCE] GIT 0.99.9l aka 1.0rc4","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-12-04T20:16:09Z","receivedAt":"2005-12-04T20:16:09Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> GIT 0.99.9l aka 1.0rc4 is found at a new location.\n\nWhat would that new location be?\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"13178","messageId":"43935658.8030707@zytor.com","threadId":"1386","inReplyTo":"200512042016.jB4KGEIt031938@pincoya.inf.utfsm.cl","subject":"Re: [ANNOUNCE] GIT 0.99.9l aka 1.0rc4","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2005-12-04T20:49:28Z","receivedAt":"2005-12-04T20:49:28Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Horst von Brand wrote:\n> Junio C Hamano wrote:\n> \n>>GIT 0.99.9l aka 1.0rc4 is found at a new location.\n> \n> What would that new location be?\n\nIf you get RPMS, you want to get them from:\n\nhttp://www.kernel.org/pub/software/scm/git/RPMS/$basearch/\n\nI don't believe non-RPMs have changed.\n\n\t-hpa\n"},{"id":"13935","messageId":"200512220027.jBM0RetQ003481@laptop11.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: [PATCH] off-by-one bugs found by valgrind","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2005-12-22T00:27:40Z","receivedAt":"2005-12-22T00:27:40Z","isPatch":true,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> Pavel Roskin writes:\n\n[...]\n\n> > quote_c_style_counted() in quote.c uses a dangerous construct, when a\n> > variable is incremented once and used twice in the same expression.\n> \n> Sorry, I do not follow you. Isn't && a sequence point?\n> \n> > -\tfor (sp = name; (ch = *sp++) && (sp - name) <= namelen; ) {\n> > -\n> > +\tfor (sp = name; sp < name + namelen; sp++) {\n\nYes, it is, so it doesn't fix any bugs; but Pavel's version is definitely\nmore readable.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"15181","messageId":"200601280455.k0S4tx6N003251@laptop11.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: Notes on Subproject Support","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-01-28T04:55:59Z","receivedAt":"2006-01-28T04:55:59Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> This is still a draft/WIP, but \"release early\" is a good\n> discipline, so...\n\nOne thing that has bugged me from the beginning of this, and which does\ncome out of your example: Why only project/subproject? In your example, you\nhave the kernel (OK(ish)) and \"rest of the world\", which could itself break\nup and be tracking e.g. uClibc, and dhcp, and... And perhaps the kernel\nitself breaks up into (local and vanilla) components.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"15184","messageId":"7vfyn8t4e5.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"200601280455.k0S4tx6N003251@laptop11.inf.utfsm.cl","subject":"Re: Notes on Subproject Support","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-01-28T21:43:30Z","receivedAt":"2006-01-28T21:43:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Horst von Brand writes:\n\n> One thing that has bugged me from the beginning of this, and which does\n> come out of your example: Why only project/subproject? In your example, you\n> have the kernel (OK(ish)) and \"rest of the world\",...\n\nBecause I presented the example badly, perhaps?\n\nThere is nothing that prevents you from having more \"bind\" lines\nthan the example showed, to have one project that works with N\nsubprojects. In fact, the examples in earlier threads used a\nproject with the kernel and gcc subprojects -- I just felt it\nwas so obvious you can do N subprojects instead of just one, so\nused just one subproject in the latest round of example for the\nsake of brevity.\n\nAnd there is nothing that prevents you from having \"bind\" lines\nin the subproject commit objects, either.\n\nThe structure the lower level objects support with the \"bound\ncommit\" extension is not about \"project vs subproject\". You can\nexpress \"project that has subprojects each of which has\nsubsubprojects\".\n\nNow, it is totally a separate issue that anybody sane would want\nto keep track of such structure, or we would be better off\nleaving it to build infrastructure specific to each toplevel\nproject, as argued by some earlier.\n"},{"id":"21182","messageId":"200606040202.k5422b7X016612@laptop11.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: [PATCH 0/27] Documentation: Spelling fixes","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-06-04T02:02:36Z","receivedAt":"2006-06-04T02:02:36Z","isPatch":true,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> Most do not seem to be typoes, depending on where you learned\n> the language (XYZour vs XYZor; ok, Ok, and OK; ie vs i.e.). I\n> favour the latter two changes myself, but honestly, I do not\n> deeply care that much. The rest are real typos.\n> \n> It seems that 1/27 did not make here, nor either of the two big\n> mailing list archives (gmane and marc).\n\nJust resent it alone.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"21322","messageId":"200606061542.k56Fg9Cm006226@laptop11.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-06-06T15:42:09Z","receivedAt":"2006-06-06T15:42:09Z","isPatch":true,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> Horst von Brand writes:\n> \n> >> > \t# check for a local address:\n> >> > -\treturn $address if ($address =~ /^([\\w\\-]+)$/);\n> >> > +\treturn $address if ($address =~ /^([\\w\\-.]+)$/);\n> >> \n> >> I keep forgetting this, '+' is a valid (and useful) setup, too.\n> >\n> > Oops...\n> >> \n> >> Actually, I'm retracting my earlier ack on this. This is way too\n> >> restrictive. I'd rather allow an occasional invalid email address than\n> >> to reject valid ones. I generally trust git users to know what they're\n> >> doing when entering email addresses[1].\n> >> \n> >> *, $, ^, +, = are all valid characters in the username portion (not sure\n> >> about local accounts, though), and I'm sure there are more that I don't\n> >> know about.\n> >\n> > As a general principle, I prefer to check what is legal instead of trying\n> > to filter out what isn't.\n\n> If we start doing addr-spec in RFC2822 (page 17) ourselves, we\n> should rather be using Email::Valid. A permissive sanity check\n> to catch obvious mistakes would be more appropriate here than\n> being RFC police.\n\nOK.\n\n> I think something like the attached, on top of your patch, would\n> be appropriate for upcoming 1.4.0.\n> \n> -- >8 --\n> send-email: be more lenient and just catch obvious mistakes.\n> \n> This cleans up the pattern matching subroutine by introducing\n> two variables to hold regexp to approximately match local-part\n> and domain in the e-mail address. It is meant to catch obvious\n> mistakes with a cheap check.\n> \n> The patch also moves \"scalar\" to force Email::Valid->address()\n> to work in !wantarray environment to extract_valid_address;\n> earlier it was in the caller of the subroutine, which was way\n> too error prone.\n\nRight.\n\n> ---\n> diff --git a/git-send-email.perl b/git-send-email.perl\n> index a7a7797..700d0c3 100755\n> --- a/git-send-email.perl\n> +++ b/git-send-email.perl\n> @@ -312,16 +312,18 @@ our ($message_id, $cc, %mail, $subject, \n> \n> sub extract_valid_address {\n> \tmy $address = shift;\n> +\tmy $local_part_regexp = '[^<>\"\\s@]+';\n> +\tmy $domain_regexp = '[^.<>\"\\s@]+\\.[^<>\"\\s@]+';\n\nThis forces a '.' in the domain, while vonbrand@localhost is perfectly\nreasonable. Plus it doesn't disallow adyacent '.'s. What about:\n\n my $domain_regexp = '[^.<>\"\\s@]+(\\.[^<>\"\\s@]+)*';\n\n(but this is probably nitpicking...)\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"21324","messageId":"7vpshmth3q.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"200606061542.k56Fg9Cm006226@laptop11.inf.utfsm.cl","subject":"Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-06T15:54:17Z","receivedAt":"2006-06-06T15:54:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Horst von Brand writes:\n\n>> diff --git a/git-send-email.perl b/git-send-email.perl\n>> index a7a7797..700d0c3 100755\n>> --- a/git-send-email.perl\n>> +++ b/git-send-email.perl\n>> @@ -312,16 +312,18 @@ our ($message_id, $cc, %mail, $subject, \n>> \n>> sub extract_valid_address {\n>> \tmy $address = shift;\n>> +\tmy $local_part_regexp = '[^<>\"\\s@]+';\n>> +\tmy $domain_regexp = '[^.<>\"\\s@]+\\.[^<>\"\\s@]+';\n>\n> This forces a '.' in the domain, while vonbrand@localhost is perfectly\n> reasonable. Plus it doesn't disallow adyacent '.'s. What about:\n>\n> my $domain_regexp = '[^.<>\"\\s@]+(\\.[^<>\"\\s@]+)*';\n>\n> (but this is probably nitpicking...)\n\nI do not have preference either way about allowing an address\nlike tld-administrator@net myself, but Email::Valid->address\ndoes not seem to allow it, and I just copied that behaviour for\nconsistency between two alternative implementations.\n\nI think you meant to say:\n\n> my $domain_regexp = '[^.<>\"\\s@]+(\\.[^.<>\"\\s@]+)*';\n\n(i.e. exclude dot from the latter character class), but I am\ninclined to do this instead:\n\n\tmy $domain_regexp = '[^.<>\"\\s@]+(?:\\.[^.<>\"\\s@]+)+';\n\n(i.e. still require at least two levels).\n"},{"id":"21325","messageId":"200606061605.k56G5gHo006581@laptop11.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-06-06T16:05:42Z","receivedAt":"2006-06-06T16:05:42Z","isPatch":true,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> Horst von Brand writes:\n> \n> >> diff --git a/git-send-email.perl b/git-send-email.perl\n> >> index a7a7797..700d0c3 100755\n> >> --- a/git-send-email.perl\n> >> +++ b/git-send-email.perl\n> >> @@ -312,16 +312,18 @@ our ($message_id, $cc, %mail, $subject, \n> >> \n> >> sub extract_valid_address {\n> >> \tmy $address = shift;\n> >> +\tmy $local_part_regexp = '[^<>\"\\s@]+';\n> >> +\tmy $domain_regexp = '[^.<>\"\\s@]+\\.[^<>\"\\s@]+';\n> >\n> > This forces a '.' in the domain, while vonbrand@localhost is perfectly\n> > reasonable. Plus it doesn't disallow adyacent '.'s. What about:\n> >\n> > my $domain_regexp = '[^.<>\"\\s@]+(\\.[^<>\"\\s@]+)*';\n> >\n> > (but this is probably nitpicking...)\n> \n> I do not have preference either way about allowing an address\n> like tld-administrator@net myself, but Email::Valid->address\n> does not seem to allow it, and I just copied that behaviour for\n> consistency between two alternative implementations.\n\nReasonable.\n\n> I think you meant to say:\n> \n> > my $domain_regexp = '[^.<>\"\\s@]+(\\.[^.<>\"\\s@]+)*';\n> \n> (i.e. exclude dot from the latter character class),\n\nRight, my bad.\n\n> but I am\n> inclined to do this instead:\n> \n> \tmy $domain_regexp = '[^.<>\"\\s@]+(?:\\.[^.<>\"\\s@]+)+';\n> \n> (i.e. still require at least two levels).\n\nOK, but be careful as this (?:...) is an extended regexp (needs /x on\nmatch). I'd just leave it plain (the performance impact shouldn't be\nnoticeable). I don't see any use except for $1, so the extra parenthesis\nshould be safe.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"21330","messageId":"7vlksate4w.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"200606061605.k56G5gHo006581@laptop11.inf.utfsm.cl","subject":"Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-06T16:58:23Z","receivedAt":"2006-06-06T16:58:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Horst von Brand writes:\n\n> Junio C Hamano wrote:\n>> but I am\n>> inclined to do this instead:\n>> \n>> \tmy $domain_regexp = '[^.<>\"\\s@]+(?:\\.[^.<>\"\\s@]+)+';\n>> \n>> (i.e. still require at least two levels).\n>\n> OK, but be careful as this (?:...) is an extended regexp (needs /x on\n> match).\n\nAre you sure about /x?\n"},{"id":"21343","messageId":"200606062124.k56LOroI007738@laptop11.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-06-06T21:24:53Z","receivedAt":"2006-06-06T21:24:53Z","isPatch":true,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> Horst von Brand writes:\n> > Junio C Hamano wrote:\n> >> but I am\n> >> inclined to do this instead:\n> >> \n> >> \tmy $domain_regexp = '[^.<>\"\\s@]+(?:\\.[^.<>\"\\s@]+)+';\n> >> \n> >> (i.e. still require at least two levels).\n> >\n> > OK, but be careful as this (?:...) is an extended regexp (needs /x on\n> > match).\n\n> Are you sure about /x?\n\nThe manual (perlop(1)) says you need /x to match extended regexps, and\n(?...) is the marker for such (perlre(1)). But my perl here (5.5.8-6 on\nFedora rawhide) doesn't care...\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"21346","messageId":"7vlksanev9.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"200606062124.k56LOroI007738@laptop11.inf.utfsm.cl","subject":"Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-06T21:39:06Z","receivedAt":"2006-06-06T21:39:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Horst von Brand writes:\n\n>> > OK, but be careful as this (?:...) is an extended regexp (needs /x on\n>> > match).\n>\n>> Are you sure about /x?\n>\n> The manual (perlop(1)) says you need /x to match extended regexps, and\n> (?...) is the marker for such (perlre(1)).\n\nI always had the impression that eXtended in the context to talk\nabout /x was about ignoring whitespaces and forcing people to\nwrite \\s (or perhaps \\040) when they mean a whitespace and had\nnothing to do with (?...) stuff. Let me look up the fine\nmanual.\n"},{"id":"21351","messageId":"200606062248.k56MmGr6008515@laptop11.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: [PATCH] Cleanup git-send-email.perl:extract_valid_email","fromName":"Horst von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-06-06T22:48:16Z","receivedAt":"2006-06-06T22:48:16Z","isPatch":true,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> Horst von Brand writes:\n> >> > OK, but be careful as this (?:...) is an extended regexp (needs /x on\n> >> > match).\n> >\n> >> Are you sure about /x?\n> >\n> > The manual (perlop(1)) says you need /x to match extended regexps, and\n> > (?...) is the marker for such (perlre(1)).\n\n> I always had the impression that eXtended in the context to talk\n> about /x was about ignoring whitespaces and forcing people to\n> write \\s (or perhaps \\040) when they mean a whitespace and had\n> nothing to do with (?...) stuff. Let me look up the fine\n> manual.\n\nYou might be right... and it even sounds sensible; but both (?...) stuff\nand the ignoring of space is described as extended here.\n\nNote that \\s is a space character (' ', '\\t', ...), which is not the same\nas \\040 (and that one assumes ASCII...).\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 654431\nUniversidad Tecnica Federico Santa Maria +56 32 654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 797513\n"},{"id":"28515","messageId":"200610101425.k9AEPLfD004981@laptop13.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: [PATCH] gitweb: Show project README if available","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-10-10T14:25:21Z","receivedAt":"2006-10-10T14:25:21Z","isPatch":true,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n\n[...]\n\n> Also we might want to consider using this file (or description)\n> for git-daemon \"motd\" action if we were to enhance it. I\n> remember that early days of git-daemon some people wanted to\n> have motd.\n\nI consider motd to be a system-wide property, not of a particular\nproject/repository...\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 2797513\n"},{"id":"28552","messageId":"200610102054.k9AKsQ2a004095@laptop13.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Junio's wishes [Was: Re: Approxidate licensing]","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-10-10T20:54:26Z","receivedAt":"2006-10-10T20:54:26Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> My wishes about the code I write for this project is very\n> simple:\n> \n> If you improve my code that had helped you to make it help\n> you even better, I would like to have that change back, so\n> that your change would help me the same way as it helped\n> you.\n> \n> The readers may have noticed that I have slight problem with\n> GPLv2; in my wish it does not matter if you distribute the\n> result or not. And I am selfish. It is not about helping my\n> users, but about helping me ;-).\n\nThere is a small practical problem with that: How would you find out I'm\nusing a modified version of your code internally? Also, the \"distribution\"\npart of GPLv2 is a useful filter: Only such modifications that are\nworthwhile to distribute get back, not each and every corner I paint myself\ninto while playing around.\n\nAll in all, a nice balance, IMVHO.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 2797513\n"},{"id":"28559","messageId":"Pine.LNX.4.64.0610101509460.3952@g5.osdl.org","threadId":"1386","inReplyTo":"200610102054.k9AKsQ2a004095@laptop13.inf.utfsm.cl","subject":"Re: Junio's wishes [Was: Re: Approxidate licensing]","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-10T22:12:04Z","receivedAt":"2006-10-10T22:12:04Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 10 Oct 2006, Horst H. von Brand wrote:\n>\n> There is a small practical problem with that: How would you find out I'm\n> using a modified version of your code internally? Also, the \"distribution\"\n> part of GPLv2 is a useful filter: Only such modifications that are\n> worthwhile to distribute get back, not each and every corner I paint myself\n> into while playing around.\n\nHey, I obviously agree that the GPLv2 is a good license, but at the same \ntime, I think too many people tend to think _just_ about legal issues.\n\nSometimes the wishes of an author should matter, regardless of whether \nthere is any law that forces you to do so. So I personally think a license \nthat says: \"if you improve this, give out the improvements regardless of \nwhether you distribute things further or not\" is a nice sentiment, and \nshould be honored, regardless of whether you can legally enforce any such \nprivate tinkering or not.\n\n\t\t\tLinus\n"},{"id":"28736","messageId":"200610131805.k9DI5QDH016016@laptop13.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: [PATCH 2/2] git-repack: -b to pass --delta-base-offset","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-10-13T18:05:26Z","receivedAt":"2006-10-13T18:05:26Z","isPatch":true,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> This new option makes the resulting pack express the delta base\n> with more compact \"offset\" format.\n> \n> Signed-off-by: Junio C Hamano \n\n[...]\n\n> @@ -35,6 +35,12 @@ OPTIONS\n> \tabout people fetching via dumb protocols from it. Use\n> \twith '-d'.\n> \n> +-b::\n> +\tPass the `--delta-base-offset` to `git pack-objects`;\n> +\tsee gitlink:git-pack-objects[1]. Do not use this option\n> +\tif you want the repository to be accessible by older\n> +\tversions of git.\n> +\n\nNeed to tell which version is the cutoff (say before 1.4.3 won't work).\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 2797513\n"},{"id":"28737","messageId":"Pine.LNX.4.64.0610131423200.2435@xanadu.home","threadId":"1386","inReplyTo":"200610131805.k9DI5QDH016016@laptop13.inf.utfsm.cl","subject":"Re: [PATCH 2/2] git-repack: -b to pass --delta-base-offset","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-10-13T18:29:08Z","receivedAt":"2006-10-13T18:29:08Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 13 Oct 2006, Horst H. von Brand wrote:\n\n> Junio C Hamano wrote:\n> > This new option makes the resulting pack express the delta base\n> > with more compact \"offset\" format.\n> > \n> > Signed-off-by: Junio C Hamano \n> \n> [...]\n> \n> > @@ -35,6 +35,12 @@ OPTIONS\n> > \tabout people fetching via dumb protocols from it. Use\n> > \twith '-d'.\n> > \n> > +-b::\n> > +\tPass the `--delta-base-offset` to `git pack-objects`;\n> > +\tsee gitlink:git-pack-objects[1]. Do not use this option\n> > +\tif you want the repository to be accessible by older\n> > +\tversions of git.\n> > +\n> \n> Need to tell which version is the cutoff (say before 1.4.3 won't work).\n\nBefore and including 1.4.3 actually. \n\nOh and the description should be augmented with \"... if you want the \nrepository to be accessible by older versions of git when _not_ using \nthe native GIT protocol.\" as the native protocol is able to select \nbetween either format on the fly regardless of the on-disk pack format.\n\n\nNicolas\n"},{"id":"28799","messageId":"200610151452.k9FEqcIN003546@laptop13.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: Recent and near future backward incompatibilities","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-10-15T14:52:38Z","receivedAt":"2006-10-15T14:52:38Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> It was brought to my attention that the public git.git\n> repository cannot be cloned with older versions of git. [...]\n\nThere seem to be a bunch of incompatible changes comming up... how about\nscheduling them for a 2.0 version, soon(ish)?\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 2797513\n"},{"id":"29340","messageId":"200610201231.k9KCVQjf008998@laptop13.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: [ANNOUNCE] GIT 1.4.3","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-10-20T12:31:26Z","receivedAt":"2006-10-20T12:31:26Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> The latest feature release GIT 1.4.3 is available at the usual\n> places:\n\n[...]\n\n> rename builtin-cat-file.c => builtin-cat-file.c (0%)\n\nHuh?!\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 2797513\n"},{"id":"298737","messageId":"200610260148.k9Q1mr99007511@laptop13.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: Combined diff format documentation","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-10-26T01:48:53Z","receivedAt":"2006-10-26T01:48:53Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> Jakub Narebski writes:\n\n[...]\n\n> > 5. Hunk header is also modified: in ordinary diff we have\n> > ...\n> > It might be not obvoious that we have (number of parents + 1) '@'\n> > characters in chunk header for combined dif format.\n\n> Correct. This was done to prevent people from accidentally\n> feeding it to \"patch -p1\". In other words, we wanted to make it\n> so obvious that it is _not_ a patch.\n\nIt isn't, really... perhaps it should be made /more/ obvious (not use @ but\ne.g. &, ...)?\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\n"},{"id":"293853","messageId":"7vmz7jkcap.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"200610260148.k9Q1mr99007511@laptop13.inf.utfsm.cl","subject":"Re: Combined diff format documentation","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-26T03:04:30Z","receivedAt":"2006-10-26T03:04:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Horst H. von Brand\" writes:\n\n>> Correct. This was done to prevent people from accidentally\n>> feeding it to \"patch -p1\". In other words, we wanted to make it\n>> so obvious that it is _not_ a patch.\n>\n> It isn't, really... perhaps it should be made /more/ obvious (not use @ but\n> e.g. &, ...)?\n\nEh, sorry, what I meant was \"obvious to the tool\", so \"patch\"\nwould take notice.\n"},{"id":"296787","messageId":"200610291903.k9TJ3am7017976@laptop13.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: Generating docu in 1.4.3.3.g01929","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-10-29T19:03:36Z","receivedAt":"2006-10-29T19:03:36Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n\n[...]\n\n> and here is what I have:\n> \n> asciidoc-7.0.2-3.fc6\n> xmlto-0.0.18-13.1\n> python-2.4.3-18.fc6\n> docbook-dtds-1.0-30.1\n> package docbook-xsl is not installed\n> flex-2.5.4a-41.fc6\n> libxslt-1.1.17-1.1\n> passivetex-1.25-5.1.1\n> util-linux-2.13-0.44.fc6\n> w3m-0.5.1-14.1\n\nI've got:\n\nasciidoc-7.0.2-3.fc6\nxmlto-0.0.18-13.1\npython-2.4.4-1.fc7\ndocbook-dtds-1.0-30.1\npackage docbook-xsl is not installed\nflex-2.5.4a-41.fc6\nlibxslt-1.1.18-1\npassivetex-1.25-5.1.1\nutil-linux-2.13-0.44.fc6\nw3m-0.5.1-14.1\n\n> \"rpm -q --whatprovides docbook-xsl\" says:\n> \n> docbook-style-xsl-1.69.1-5.1\n\ndocbook-style-xsl-1.69.1-5.1\n\nDifferences are (mine (Junio's)):\n\npython-2.4.4-1.fc7 (python-2.4.3-18.fc6)\nlibxslt-1.1.18-1 (libxslt-1.1.17-1.1)\n\nlibxslt requires libxml2:\n\nlibxml2-2.6.27-1 (Fedora 6 has libxml2-2.6.26-2.1.1)\n\nGetting the Fedora 6 libxslt (Junio's) and redoing git gives no errors.\n\nJudging from the libxslt changelog they\ntightened up the processing, so I'd guess asciidoc is generating fishy XML\nor xmlto is broken. I've no clue here... somebody knowledgeable who can\ntake a closer look or otherwise lend me a hand?\n\nThanks!\n\nPS: I get similar errors with tig...\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 2797513\n\n"},{"id":"298633","messageId":"200611061646.kA6GkHgi009592@laptop13.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: [PATCH] git-pickaxe -C -C -C","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-11-06T16:46:17Z","receivedAt":"2006-11-06T16:46:17Z","isPatch":true,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> Three -C options makes the command to look for copied lines from _any_\n> existing file in the parent commit, not just changed files.\n\nIMHO, this is horrible UI.\n\n-C is one thing\n-C -C is another\n-C -C -C is still another?\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 2797513\n"},{"id":"294218","messageId":"7v3b8webdb.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"200611061646.kA6GkHgi009592@laptop13.inf.utfsm.cl","subject":"Re: [PATCH] git-pickaxe -C -C -C","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-06T17:25:04Z","receivedAt":"2006-11-06T17:25:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Horst H. von Brand\" writes:\n\n> Junio C Hamano wrote:\n>> Three -C options makes the command to look for copied lines from _any_\n>> existing file in the parent commit, not just changed files.\n>\n> IMHO, this is horrible UI.\n>\n> -C is one thing\n> -C -C is another\n> -C -C -C is still another?\n\nI think of it as \"-v\" vs \"-v -v\" vs \"-v -v -v\" some programs use\nto give you increasing levels of verbosity.\n\nTriple-C version is a kind of joke and not to be integrated\n(although it seems to work as advertised, it is inpractically\nslow), so it really is between -C vs -C -C, but certainly I am\nopen to better ways of specifying the current -C/-C -C options.\n"},{"id":"294786","messageId":"200611152113.kAFLDgZO005651@laptop13.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: Sometimes \"Failed to find remote refs\" means \"try git-fetch --no-tags\"","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-11-15T21:13:42Z","receivedAt":"2006-11-15T21:13:42Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n\n[...]\n\n> However \"fetch --no-tags\" from http upstream is a band-aid to\n> hide that the upstream repository has stale info/refs, and I do\n> not think we would want to encourage the band-aid. Rather, the\n> message should say \"yell loudly at the repository owner\" ;-).\n\nI'm seeing this gem here:\n\n [vonbrand@laptop13 git]$ git pull\n fatal: read error (Connection reset by peer)\n Fetch failure: git://git.kernel.org/pub/scm/git/git.git\n fatal: read error (Connection reset by peer)\n Failed to find remote refs\n No changes.\n\nWho shall I yell at? ;-)\n\nSeriously, this is broken. I get 4 different error messages, plus a\n(reassuring?) \"No changes\". Yes, I know this is what I'll see if the\nmachine is overloaded.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\n"},{"id":"298393","messageId":"200611201700.kAKH0msM012002@laptop13.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: [PATCH] git-merge: make it usable as the first class UI","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-11-20T17:00:48Z","receivedAt":"2006-11-20T17:00:48Z","isPatch":true,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n\n[...]\n\n> -- >8 --\n> [PATCH] git-merge: make it usable as the first class UI\n> \n> This teaches the oft-requested syntax\n> \n> \tgit merge $commit\n> \n> to implement merging the named commit to the current branch.\n> This hopefully would make \"git merge\" usable as the first class\n> UI instead of being a mere backend for \"git pull\".\n> \n> Most notably, $commit above can be any committish, so you can\n> say for example:\n> \n> \tgit merge js/shortlog~2\n> \n> to merge early part of a topic branch without merging the rest\n> of it.\n\n\"Early part\", i.e., branch js/shortlog up to js/shortlog~2 or just that one\ncommit?\n\n> A custom merge message can be given with the new --message=\n> parameter. The message is prepended in front of the usual\n> \"Merge ...\" message autogenerated with fmt-merge-message.\n\nWhy not -m too (consistency!)?\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\n"},{"id":"296397","messageId":"7vr6vx28w1.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"200611201700.kAKH0msM012002@laptop13.inf.utfsm.cl","subject":"Re: [PATCH] git-merge: make it usable as the first class UI","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-20T19:52:30Z","receivedAt":"2006-11-20T19:52:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Horst H. von Brand\" writes:\n\n>> Most notably, $commit above can be any committish, so you can\n>> say for example:\n>> \n>> \tgit merge js/shortlog~2\n>> \n>> to merge early part of a topic branch without merging the rest\n>> of it.\n>\n> \"Early part\", i.e., branch js/shortlog up to js/shortlog~2 or just that one\n> commit?\n\n\"Early part up to that commit\" -- this is not a cherry pick.\n\n>> A custom merge message can be given with the new --message=\n>> parameter. The message is prepended in front of the usual\n>> \"Merge ...\" message autogenerated with fmt-merge-message.\n>\n> Why not -m too (consistency!)?\n\nThat form also is accepted, I think.\n\n"},{"id":"295280","messageId":"200611262305.kAQN5FoO016231@laptop13.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: [PATCH] Make logAllRefUpdates true by default","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-11-26T23:05:15Z","receivedAt":"2006-11-26T23:05:15Z","isPatch":true,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n\n[...]\n\n> Having thought about all the above, I think the event to create\n> distribution/synchronization point repositories are rare enough\n> and the simplest and cleanest way might be to make it default\n> and add a --without-reflog option to the command, and forget\n> about the guessing.\n\nLooks sanest. I hate stuff that tries to outguess me by being \"smart\" (part\nof the reason I love Unixy systems).\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\n"},{"id":"297436","messageId":"200612142352.kBENq8Ie002603@laptop13.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: What's in git.git (stable)","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-12-14T23:52:08Z","receivedAt":"2006-12-14T23:52:08Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n\n[...]\n\n> In general the principle ought to be not to say anything if the\n> command does exactly what it was told to do successfully, unless\n> the operation is expected to take longer than other normal\n> commands in the git suite, or something that is rarely used.\n\nNodz. Just hoary Unix tradition.\n\n> Perhaps under \"[user] expert\" control.\n\nNope. You'd be surprised what kind of people consider themselves\n\"experts\"... I'd prefer adding -v/--verbose flags to all commands (if\nnothing else, for symmetry's sake), have a '[default] --verbose' controlling\nthis across the board (perhaps also '[default \"command\"] --verbose'), with\n'[default]' setting default switches.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 2797513\n"},{"id":"295363","messageId":"eltumg$n03$1@sea.gmane.org","threadId":"1386","inReplyTo":"200612142352.kBENq8Ie002603@laptop13.inf.utfsm.cl","subject":"Re: What's in git.git (stable)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-15T10:53:25Z","receivedAt":"2006-12-15T10:53:25Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Horst H. von Brand wrote:\n\n>> Perhaps under \"[user] expert\" control.\n> \n> Nope. You'd be surprised what kind of people consider themselves\n> \"experts\"... I'd prefer adding -v/--verbose flags to all commands (if\n> nothing else, for symmetry's sake), have a '[default] --verbose' controlling\n> this across the board (perhaps also '[default \"command\"] --verbose'), with\n> '[default]' setting default switches.\n\nNice idea... but configuration variables have to have name.\nSo it would be \n\n $ git repo-config defaults.command --verbose\n\nresulting in\n\n [defaults]\n command = --verbose\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"30346","messageId":"200612271206.kBRC6ke2004207@laptop13.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: [RFH] An early draft of v1.5.0 release notes","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-12-27T12:06:46Z","receivedAt":"2006-12-27T12:06:46Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> This is still rough, but I think we have a pretty good idea what\n> will and what won't be in v1.5.0 by now, and end-of-year is a\n> good slow time to summarize what we have done.\n\nCould somebody please summarize how to \"upgrade\" a repository to the new\nlayout? This has got my head spinning... and I'm /not/ cloning the\nvarious repos I've got here just to take advantage of the changes.\n\nThanks!\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 2797513\n"},{"id":"30382","messageId":"200612280135.kBS1ZL5v004756@laptop13.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: http git and curl 7.16.0","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-12-28T01:35:21Z","receivedAt":"2006-12-28T01:35:21Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> \"Horst H. von Brand\" writes:\n> > Sven Verdoolaege wrote:\n> >> On Sat, Nov 18, 2006 at 08:07:08AM +0400, George Sherwood wrote:\n> >> > I seem to be having a problem doing an http checkout with git built\n> >> > with curl 7.16.0 enabled. If I build against curl 7.16.0 and try a\n> >> > clone, I get:\n> > ...\n> >> > git clone http://dmlb2000.homelinux.org/~dmlb2000/git-repos/local/castfs.git\n> >> > error: Unable to start request error: Could not interpret heads/master\n> >> > as something to pull\n> >> > \n> >> > If I rebuild git against curl 7.15.5 then I get:\n> >> [..]\n> >> > and the checkout finishes.\n> >> > \n> >> > Has any one else seen this?\n> >\n> >> FWIW, I've seen the same with curl 7.16.0 on a Solaris 9 machine.\n> >> It worked fine with curl 7.15.0.\n> >\n> > It works fine for me on Aurora Corona (sparc) with curl-7.15.5-1.al3, while\n> > it fails as above on Fedora rawhide (i386) with curl-7.16.0-4.fc7.\n> >\n> > Furthermore, with new curl pulling from HTTP repos when there are updates\n> > gives double free errors and a crash.\n> \n> Hmmm. Could somebody please run http-fetch under gdb and see\n> where it breaks? The exact command line you need to use would\n> be obtainable by running \"sh -x git-clone\" once.\n\nIt crashes the kernel for me here :-(\n\nI tried to chop down a tig repo a few commits from the top for checking out\nthe crash I'm seeing (only when pulling from a remote repo by HTTP, and it\nis not up to date here) by doing:\n\n cp -r tig tig.tst\n cd tig.tst\n git reset --hard HEAD~3\n git prune\n\nBut now git-pull /doesn't/ fetch anything, so I see no crash. What am I\ndoing wrong here?\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 2797513\n"},{"id":"30383","messageId":"20061228014225.GB16612@spearce.org","threadId":"1386","inReplyTo":"200612280135.kBS1ZL5v004756@laptop13.inf.utfsm.cl","subject":"Re: http git and curl 7.16.0","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-12-28T01:42:25Z","receivedAt":"2006-12-28T01:42:25Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Horst H. von Brand\" wrote:\n> I tried to chop down a tig repo a few commits from the top for checking out\n> the crash I'm seeing (only when pulling from a remote repo by HTTP, and it\n> is not up to date here) by doing:\n> \n> cp -r tig tig.tst\n> cd tig.tst\n> git reset --hard HEAD~3\n> git prune\n> \n> But now git-pull /doesn't/ fetch anything, so I see no crash. What am I\n> doing wrong here?\n\nAnother ref points at the same commit as what ORIG_HEAD points at,\nso there wasn't anything to fetch as you already had that commit.\n\nIts probably a tag, a ref under refs/remotes, or another branch...\n\n-- \nShawn.\n"},{"id":"30397","messageId":"7v64bw3ewk.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"200612271206.kBRC6ke2004207@laptop13.inf.utfsm.cl","subject":"Re: [RFH] An early draft of v1.5.0 release notes","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-28T02:58:19Z","receivedAt":"2006-12-28T02:58:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Horst H. von Brand\" writes:\n\n> Junio C Hamano wrote:\n>> This is still rough, but I think we have a pretty good idea what\n>> will and what won't be in v1.5.0 by now, and end-of-year is a\n>> good slow time to summarize what we have done.\n>\n> Could somebody please summarize how to \"upgrade\" a repository to the new\n> layout? This has got my head spinning... and I'm /not/ cloning the\n> various repos I've got here just to take advantage of the changes.\n\nThe old layout was to map remote branch $B to local tracking\nbranch .git/refs/heads/$B, unless $B == 'master' in which case\nit was mapped to .git/refs/heads/origin (and I think we\ndiscarded 'origin' at remote).\n\nEach remote branch $B is tracked with .git/refs/remote/origin/$B\nin the new layout.\n\nAnd you will get something like this in your .git/config:\n\n [remote \"origin\"]\n url = git://git.kernel.org/pub/scm/.../torvalds/linux-2.6.git/\n fetch = refs/heads/*:refs/remotes/origin/*\n [branch \"master\"]\n remote = origin\n merge = refs/heads/master\n\nThe first section defines what the token 'origin' means when you\nsay \"git pull origin\" or \"git fetch origin\". remote.origin.url\ndefines the URL to fetch/pull from, and remote.origin.fetch\nsupplies the refspecs you omitted from the command line (fetch\neverything from refs/heads/ hierarchy of remote and store them\nin my refs/remotes/origin/ hierarchy).\n\nThe second section defines what happens when you say \"git pull\"\nor \"git fetch\" while on your \"master\" branch. It tells that you\nmeant to say \"git pull origin\" or \"git fetch origin\" when you\nomitted the URL argument from the command line. And because you\nare also omitting the refspecs, remote.origin.fetch kicks in and\nslurps all the branches from the remote side and stores them in\nyour refs/remotes/origin/ hierarchy. When the command was \"git\npull\", it also says the merge that follows the fetch is to merge\nthe 'master' branch at the remote side (which happens to be\ncopied to your remotes/origin/master only because you have\nremote.origin.fetch) into your current branch (which is\n\"master\", because this section is about what happens while you\nare on your \"master\" branch).\n\nSo for an existing repository that does not use the separate\nremotes layout, you can easily convert that by hand if you\nwanted to by:\n\n - Move tracking branches from refs/heads/* to\n refs/remotes/origin/*,\n\n - create the config section like the above in .git/config, and\n\n - remove .git/remotes/origin when you are done.\n"},{"id":"30436","messageId":"en0asv$bjm$1@sea.gmane.org","threadId":"1386","inReplyTo":"7v64bw3ewk.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFH] An early draft of v1.5.0 release notes","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-28T11:50:37Z","receivedAt":"2006-12-28T11:50:37Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"[Cc: git@vger.kernel.org, Junio C Hamano ,\n \"Horst H. von Brand\" ]\n\nJunio C Hamano wrote:\n\n> \"Horst H. von Brand\" writes:\n> \n>> Junio C Hamano wrote:\n>>> This is still rough, but I think we have a pretty good idea what\n>>> will and what won't be in v1.5.0 by now, and end-of-year is a\n>>> good slow time to summarize what we have done.\n>>\n>> Could somebody please summarize how to \"upgrade\" a repository to the new\n>> layout? This has got my head spinning... and I'm /not/ cloning the\n>> various repos I've got here just to take advantage of the changes.\n> \n> The old layout was to map remote branch $B to local tracking\n> branch .git/refs/heads/$B, unless $B == 'master' in which case\n> it was mapped to .git/refs/heads/origin (and I think we\n> discarded 'origin' at remote).\n\nHow to discard 'origin' in the new wildcard / globbing remote config?\nIIRC there was proposal to use '-' or '!' to exclude branch from\nfetching, but no code...\n\n[...]\n> - create the config section like the above in .git/config, and\n\nYou can use contrib/remotes2config.sh script...\n\n> - remove .git/remotes/origin when you are done.\n \n...which saves remotes/ under remotes.old/\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"30472","messageId":"200612291237.kBTCbq0P010010@laptop13.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: [PATCH/RFT] Work around http-fetch built with cURL 7.16.0","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2006-12-29T12:37:52Z","receivedAt":"2006-12-29T12:37:52Z","isPatch":true,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> It appears that curl_easy_duphandle() from libcurl 7.16.0\n> returns a curl session handle which fails GOOD_MULTI_HANDLE()\n> check in curl_multi_add_handle(). This causes fetch_ref() to\n> fail because start_active_slot() cannot start the request.\n> \n> For now, check for 7.16.0 to work this issue around.\n> \n> Signed-off-by: Junio C Hamano \n> ---\n> \n> * I think people who were having trouble with cURL 7.16.0 want\n> to have the issue resolved before v1.5.0-rc1. Please test\n> and report, or else ;-).\n\nChecked it out. Now clone and pull both work here.\n\nThanks!\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 2797513\n"},{"id":"31138","messageId":"200701081330.l08DUd7H023896@laptop13.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: [ANNOUNCE] GIT 1.4.4.4","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2007-01-08T13:30:39Z","receivedAt":"2007-01-08T13:30:39Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> The latest maintenance release GIT 1.4.4.4 is available at the\n> usual places:\n> \n> http://www.kernel.org/pub/software/scm/git/\n> \n> git-1.4.4.4.tar.{gz,bz2}\t\t\t(tarball)\n> git-htmldocs-1.4.4.4.tar.{gz,bz2}\t\t(preformatted docs)\n> git-manpages-1.4.4.4.tar.{gz,bz2}\t\t(preformatted docs)\n> RPMS/$arch/git-*-1.4.4.4-1.$arch.rpm\t(RPM)\n> \n> This is to push out a handful bugfixes since 1.4.4.3.\n> \n> On the 'master' development front, the stabilization for v1.5.0\n> will start soonish.\n\nI get git version 1.4.4.4.g9a5e4 (used to be 1.5.0.rc0.gXXXX) on the msater\nbranch now?\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 2797513\n"},{"id":"31583","messageId":"200701122015.l0CKFB8j022355@laptop13.inf.utfsm.cl","threadId":"1386","inReplyTo":"junkio@cox.net","subject":"Re: 1.5.0.rc1.g4494: Can't use a bare GIT_DIR to add","fromName":"Horst H. von Brand","fromEmail":"vonbrand@inf.utfsm.cl","sentAt":"2007-01-12T20:15:11Z","receivedAt":"2007-01-12T20:15:11Z","isPatch":false,"sender":{"key":"vonbrand@inf.utfsm.cl","avatar":"https://avatars.githubusercontent.com/u/211384?v=4"},"body":"Junio C Hamano wrote:\n> \"Horst H. von Brand\" writes:\n> \n> > I tried this:\n> > \n> > mkdir xyz\n> > cd xyz\n> > git --git-dir=../xyz.git \n> > # Initialized empty Git repository in ../xyz.git/\n> > echo Junk > file-a\n> > git --git-dir=../xyz.git add .\n> > # fatal: add cannot be used in a bare git directory\n> >\n> > I expected that \"GIT_DIR is bare, over there, stuff is here\" works the same\n> > as \"GIT_DIR is .git, right here among stuff\".\n\n> Sheesh, why didn't you speak out earlier while the discussion\n> was on (I am not serious, git mailing list is still moving too\n> fast for people to be always on top of)?\n\nBecause I just noticed :-(\n\n> Now, seriously.\n\n[...]\n\n> You said \"I tried\". Is this something you do in real life?\n\nThere was a discussion going on about importing several tarballs (one\nversion after the other) into git. If you want to just export the result,\nnot futz around in it, it leads naturally to doing something like:\n\n mkdir /base/test.git\n cd /base/test.git; git --bare init\n for v in 0.8.0.99 0.99a 0.99b 1.0 1.1 1.2.0 1.2.1 1.2.2; do\n cd /work\n tar zxf test-$v.tar.gz\n cd test-$v\n git --git-dir=/base/test.git add .\n git --git-dir=/base/test.git commit -a \"Version $v\"\n git --git-dir=/base/test.git tag v$v\n cd /work\n rm -rf test-$v\n done\n\n> This _is_ a regression, as we are checking something we did not\n> check before and refusing to work in cases where we did. But I\n> am not sure if reverting to lift the safety (for that matter,\n> introducing the third \"depends\" alternative) is better than the\n> latest behaviour.\n\nIt grates me somewhat that there isn't a clean way of saying \"My .git stuff\nis over there\". No big deal, really.\n\nAnd it is not a \"depends\", AFAICS: GIT_DIR says where to stash stuff, users\nhad better know what they are doing in that case... so perhaps allow\nanything if GIT_DIR is set?\n\n> For one thing, you could (sometime before the \"git add .\" and do\n> this only once) do:\n> \n> \t$ ln -s ../xyz.git .git\n> \n> and that would make all the future git operation work without\n> the --git-dir parameter (or GIT_DIR environment) in xyz\n> directory. An added benefit is that it would even allow git\n> command to work from a subdirectory of xyz (specifying GIT_DIR\n> or --git-dir means you are bypassing the discovery for the top\n> of the working tree, so you have to always be at the top).\n\nFor this particular case this is no real help.\n\nBut no big deal to me. Still trying to wrap my brain aound git, that's all.\n-- \nDr. Horst H. von Brand User #22616 counter.li.org\nDepartamento de Informatica Fono: +56 32 2654431\nUniversidad Tecnica Federico Santa Maria +56 32 2654239\nCasilla 110-V, Valparaiso, Chile Fax: +56 32 2797513\n"},{"id":"31596","messageId":"7vps9kq6aa.fsf@assigned-by-dhcp.cox.net","threadId":"1386","inReplyTo":"200701122015.l0CKFB8j022355@laptop13.inf.utfsm.cl","subject":"Re: 1.5.0.rc1.g4494: Can't use a bare GIT_DIR to add","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-12T21:33:33Z","receivedAt":"2007-01-12T21:33:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Horst H. von Brand\" writes:\n\n> Junio C Hamano wrote:\n> ...\n>> This _is_ a regression, as we are checking something we did not\n>> check before and refusing to work in cases where we did. But I\n>> am not sure if reverting to lift the safety (for that matter,\n>> introducing the third \"depends\" alternative) is better than the\n>> latest behaviour.\n>\n> It grates me somewhat that there isn't a clean way of saying \"My .git stuff\n> is over there\". No big deal, really.\n>\n> And it is not a \"depends\", AFAICS: GIT_DIR says where to stash stuff, users\n> had better know what they are doing in that case... so perhaps allow\n> anything if GIT_DIR is set?\n\nOne problem I have with that is that doing so would make it\nharder to prevent pushing into the current branch of a\nrepository with working tree from happening later.\n\nIn the \"sequence of tarballs\" example, I wonder why you cannot\ndo something like:\n\n\tgit init-db\n\tfor tarball\n do\n \ttar xf $tarball\n # if it extracts in a wrong directory, move them\n # up first ...\n git add .\n git commit -a\n\t\tgit rm -r .\n\tdone\n"}]}