{"thread":{"id":"5671","subject":"What will happen to git.git in the near future","startedAt":"2006-09-24T10:37:57Z","lastAt":"2006-10-01T20:23:16Z","messageCount":13,"participants":["Junio C Hamano","Petr Baudis","Rene Scharfe","Johannes Schindelin","A Large Angry SCM","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"27536","messageId":"7v7iztbldm.fsf@assigned-by-dhcp.cox.net","threadId":"5671","inReplyTo":null,"subject":"What will happen to git.git in the near future","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-09-24T10:37:57Z","receivedAt":"2006-09-24T10:37:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are some random thoughts on the short-term plan. We are\ncurrently at 1.4.2 release (and \"maint\" is at 1.4.2.1).\n\nI do not know when the changes are big enough to start the 1.5\nseries, so tentatively I'll call the next one 1.4.3, the one\nthat follows 1.4.4, and so on, in the following description.\n\n - git-resolve is deprecated on \"master\" and will continue to be\n so until 1.4.3. We will remove it before 1.4.4 happens.\n\n - We will deprecate the original merge-recursive written in\n Python by renaming it to merge-recursive-old, and make\n merge-recur to take its place. 1.4.3 will ship that way.\n Sometime in not so distant future we will remove\n merge-recursive-old and merge-recur, perhaps in 1.4.5.\n\n - We should deprecate git-tar-tree. However, it has been\n around and advertised for quite some time, so we need to make\n sure people would not get burned too badly. It might be\n worthwhile to rewrite git-tar-tree as a thin wrapper to\n \"git-archive --format=tar\" and remove git-upload-tar now (in\n other words, \"git-tar-tree --remote\" will continue to work,\n but it will talk with \"git-upload-archive\", not with\n \"git-upload-tar\" on the other end), release 1.4.3 with it\n with a deprecation warning, and then remove it in 1.4.5.\n\n - virtual hosting by git-daemon should be ready. I will push\n it out to \"master\" before 1.4.3 release.\n\n - packed-refs still has a few issues before it can hit\n \"master\". \n\n - deleting branches does not really work yet, as there have\n been some discussions on the list.\n\n - dumb transports are unaware of it. Trying to fetch a\n ref that is packed would not work.\n\n I feel this series to be a significant enough change that\n deserve a bit careful handling. Perhaps in 1.4.4 release.\n\n - The per-branch configuration to control git-fetch is Ok in\n itself, and we might want to push it out to \"master\" and\n release 1.4.3 with it in its current form. But the topic\n might want to learn other tricks to have more comprehensive\n per-branch configuration support. We will see how it plays\n out.\n\n - Git.pm lost Git.xs which hopefully would make it a bit easier\n to work for wider audiences. Hopefully we can push it out to\n \"master\" soon and see if anybody screams. Depending on what\n happens, it may be in 1.4.3 release.\n\n - git-show-ref and git-for-each-ref serve similar purpose (when\n viewed in a bigger picture) but with different interface and\n different set of features. We should consolidate them into\n one command before they hit in any released version.\n\n - git-log's support for --committer=, --author= and --grep= is\n Ok by itself, but I feel we should do a bit more to make it\n useful. Currently we cannot say \"written by A and committed\n by B\", or \"written by C and have word D in the log\". Because\n the boolean logic between match patterns we use internally\n are line oriented, borrowing --and from git-grep is not\n enough (\"--committer=A --and --author=B\" would mean 'if the\n commit object has a header line that matches \"^committer .*A\"\n and \"^author .*B\" at the same time', which is not what we\n want). We would need a \"buffer-wide AND\" that can express\n 'see if there is a header line that matches \"^committer .*A\"\n and a header line, which may be different from the\n \"committer\" one, that matches \"^author .*B\"'.\n\n Implementing \"buffer-wide AND\" will involve updating git-grep\n but as a side effect we will also be able to say \"find files\n that have word A and B in them\", which would be a useful\n thing. I'd push the current implementation out to \"master\"\n soon and release 1.4.3 with it, and defer implementation of\n the buffer-wide AND to a later version.\n\n - generation of version 3 pack files is 1.4.3 material.\n\n - new pack object format to express delta base object by the\n offset in the stream will start cooking in \"next\" soon; I\n just haven't got around to merge it yet. I feel this to be\n significant enough change that can deserve a bit careful\n handling. Perhaps in 1.4.4 or 1.4.5 release.\n\n - windowed mmap() of pack data is an important change (I do not\n mean to pressure Shawn by saying this) and needs to be cooked\n carefully. I do not expect it to be ready until 1.4.5\n release at the earliest.\n"},{"id":"27539","messageId":"20060924110429.GJ20017@pasky.or.cz","threadId":"5671","inReplyTo":"7v7iztbldm.fsf@assigned-by-dhcp.cox.net","subject":"Re: What will happen to git.git in the near future","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-09-24T11:04:29Z","receivedAt":"2006-09-24T11:04:29Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"Dear diary, on Sun, Sep 24, 2006 at 12:37:57PM CEST, I got a letter\nwhere Junio C Hamano said that...\n> - git-resolve is deprecated on \"master\" and will continue to be\n> so until 1.4.3. We will remove it before 1.4.4 happens.\n\nWoo-hoo!\n\n> - We should deprecate git-tar-tree. However, it has been\n> around and advertised for quite some time, so we need to make\n> sure people would not get burned too badly. It might be\n> worthwhile to rewrite git-tar-tree as a thin wrapper to\n> \"git-archive --format=tar\" and remove git-upload-tar now (in\n> other words, \"git-tar-tree --remote\" will continue to work,\n> but it will talk with \"git-upload-archive\", not with\n> \"git-upload-tar\" on the other end), release 1.4.3 with it\n> with a deprecation warning, and then remove it in 1.4.5.\n\nI believe this is way too rushed, please consider keeping git-tar-tree\nas the thin wrapper _much_ longer.\n\nWe still have ssh-pull and ssh-push around after more than a year of\ntheir deprecation. (BTW, we might as well consider removing those. ;)\n\n> - packed-refs still has a few issues before it can hit\n> \"master\". \n> \n> - deleting branches does not really work yet, as there have\n> been some discussions on the list.\n> \n> - dumb transports are unaware of it. Trying to fetch a\n> ref that is packed would not work.\n\nThis is a big problem.\n\n> I feel this series to be a significant enough change that\n> deserve a bit careful handling. Perhaps in 1.4.4 release.\n\nI agree, there are some subtle changes there (like the heads ordering)\nthat could cause unforeseen problems, better be careful about it.\n\n> - Git.pm lost Git.xs which hopefully would make it a bit easier\n> to work for wider audiences. Hopefully we can push it out to\n> \"master\" soon and see if anybody screams. Depending on what\n> happens, it may be in 1.4.3 release.\n\nWoo-hoo!\n\n> - git-show-ref and git-for-each-ref serve similar purpose (when\n> viewed in a bigger picture) but with different interface and\n> different set of features. We should consolidate them into\n> one command before they hit in any released version.\n\nDo I understand it correctly that those are the only interfaces for\nscripts to access packed refs?\n\nIdeally there would be some transition period provided so that I can\nteach Cogito about them without having it broken for repositories with\npacked refs for some time. But since packing refs is optional and\nexplicit action, perhaps it's not so critical.\n\nStill, I looked forward for having those tools in the next release so\nthat Cogito can use them. Oh well. :)\n\n> Implementing \"buffer-wide AND\" will involve updating git-grep\n> but as a side effect we will also be able to say \"find files\n> that have word A and B in them\", which would be a useful\n> thing. I'd push the current implementation out to \"master\"\n> soon and release 1.4.3 with it, and defer implementation of\n> the buffer-wide AND to a later version.\n\nYes. Those options are cool as they are and they can speed up gitweb's\nsearch as well as cg-log -u.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i - We should deprecate git-tar-tree. However, it has been\n> around and advertised for quite some time, so we need to make\n> sure people would not get burned too badly. It might be\n> worthwhile to rewrite git-tar-tree as a thin wrapper to\n> \"git-archive --format=tar\" and remove git-upload-tar now (in\n> other words, \"git-tar-tree --remote\" will continue to work,\n> but it will talk with \"git-upload-archive\", not with\n> \"git-upload-tar\" on the other end), release 1.4.3 with it\n> with a deprecation warning, and then remove it in 1.4.5.\n\nHmm. The local case in git-tar-tree is already a thin wrapper.\nHow about something like this shell script as a replacement for\nthe entire command?\n\nRené\n\n--- snip! --\n#!/bin/sh\n#\n# Copyright (C) 2006 Rene Scharfe\n\nUSAGE='[--remote=] [basedir]'\n. git-sh-setup\n\ncase \"$1\" in\n--remote=*)\tremote=1;;\n*)\t\tremote=0;;\nesac\n\ncase \"$#,$remote\" in\n1,0)\texec git-archive --format=tar \"$1\";;\n2,0)\texec git-archive --format=tar --prefix=\"$2\"/ \"$1\";;\n2,1)\texec git-archive --format=tar \"$1\" \"$2\";;\n3,1)\texec git-archive --format=tar --prefix=\"$3\"/ \"$1\" \"$2\";;\n*)\tusage;;\nesac\n"},{"id":"27571","messageId":"Pine.LNX.4.63.0609242031410.25371@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5671","inReplyTo":"4516B8A7.6010007@lsrfire.ath.cx","subject":"Re: What will happen to git.git in the near future","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-09-24T18:33:26Z","receivedAt":"2006-09-24T18:33:26Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 24 Sep 2006, Rene Scharfe wrote:\n\n> Junio C Hamano schrieb:\n> > - We should deprecate git-tar-tree. However, it has been\n> > around and advertised for quite some time, so we need to make\n> > sure people would not get burned too badly. It might be\n> > worthwhile to rewrite git-tar-tree as a thin wrapper to\n> > \"git-archive --format=tar\" and remove git-upload-tar now (in\n> > other words, \"git-tar-tree --remote\" will continue to work,\n> > but it will talk with \"git-upload-archive\", not with\n> > \"git-upload-tar\" on the other end), release 1.4.3 with it\n> > with a deprecation warning, and then remove it in 1.4.5.\n> \n> Hmm. The local case in git-tar-tree is already a thin wrapper.\n> How about something like this shell script as a replacement for\n> the entire command?\n\nI think that this could be done very efficiently (both in terms of time \nand size) as a \"pure\" builtin, i.e. something with works as\n\"git tar-tree\", but not as \"git-tar-tree\". Of course, this would break \nscripts using the latter instead of the former. Just my 2 yinyangs.\n\nCiao,\nDscho\n"},{"id":"27572","messageId":"4516D190.3020608@gmail.com","threadId":"5671","inReplyTo":"Pine.LNX.4.63.0609242031410.25371@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: What will happen to git.git in the near future","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2006-09-24T18:42:24Z","receivedAt":"2006-09-24T18:42:24Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n[...]\n> I think that this could be done very efficiently (both in terms of time \n> and size) as a \"pure\" builtin, i.e. something with works as\n> \"git tar-tree\", but not as \"git-tar-tree\". Of course, this would break \n> scripts using the latter instead of the former. Just my 2 yinyangs.\n\nThat would be a bug. If \"git foo\" works, then \"git-foo\" should also work.\n"},{"id":"28059","messageId":"7vd59c2vev.fsf@assigned-by-dhcp.cox.net","threadId":"5671","inReplyTo":"7v7iztbldm.fsf@assigned-by-dhcp.cox.net","subject":"Re: What will happen to git.git in the near future","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-01T10:16:24Z","receivedAt":"2006-10-01T10:16:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I've tagged the tip of the master as v1.4.3-rc1 tonight, after\nmerging things that I listed in the message last week to be\nmerged from \"next\".\n\nHave fun.\n"},{"id":"28068","messageId":"Pine.LNX.4.64.0610011132040.3952@g5.osdl.org","threadId":"5671","inReplyTo":"7vd59c2vev.fsf@assigned-by-dhcp.cox.net","subject":"Re: What will happen to git.git in the near future","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-01T18:38:06Z","receivedAt":"2006-10-01T18:38:06Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 1 Oct 2006, Junio C Hamano wrote:\n>\n> I've tagged the tip of the master as v1.4.3-rc1 tonight, after\n> merging things that I listed in the message last week to be\n> merged from \"next\".\n> \n> Have fun.\n\nI hate that perl crud.\n\n\t...\n\tmake -C perl\n\tmake[1]: Entering directory `/home/torvalds/git/perl'\n\tcp private-Error.pm blib/lib/Error.pm\n\tcp Git.pm blib/lib/Git.pm\n\tgcc -c -D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m32 -DVERSION=\\\"0.01\\\" -DXS_VERSION=\\\"0.01\\\" -fPIC \"-I/usr/lib/perl5/5.8.8/ppc-linux-thread-multi/CORE\" Git.c\n\tIn file included from Git.xs:8:\n\t../cache.h:6:10: error: #include expects \"FILENAME\" or \n\tGit.xs: In function 'XS_Git_xs_version':\n\tGit.xs:62: error: 'GIT_VERSION' undeclared (first use in this function)\n\tGit.xs:62: error: (Each undeclared identifier is reported only once\n\tGit.xs:62: error: for each function it appears in.)\n\tmake[1]: *** [Git.o] Error 1\n\tmake[1]: Leaving directory `/home/torvalds/git/perl'\n\tmake: *** [all] Error 2\n\nI don't like how git now doesn't compile just out of the box on a \nperfectly regular FC5 box.\n\nThe whole Git.xs stuff has been buggered from the very beginning, at some \npoint somebody needs to just admit it. \n\nPlease?\n\nAnd how come does this actually work for anybody else? I've got PPC_SHA1 \ndefined, but I don't see what the difference is..\n\n\t\tLinus\n"},{"id":"28070","messageId":"7vlknz27qm.fsf@assigned-by-dhcp.cox.net","threadId":"5671","inReplyTo":"Pine.LNX.4.64.0610011132040.3952@g5.osdl.org","subject":"Re: What will happen to git.git in the near future","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-10-01T18:47:45Z","receivedAt":"2006-10-01T18:47:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Sun, 1 Oct 2006, Junio C Hamano wrote:\n>>\n>> I've tagged the tip of the master as v1.4.3-rc1 tonight, after\n>> merging things that I listed in the message last week to be\n>> merged from \"next\".\n>> \n>> Have fun.\n>\n> I hate that perl crud.\n>...\n> \tGit.xs: In function 'XS_Git_xs_version':\n> \tGit.xs:62: error: 'GIT_VERSION' undeclared (first use in this function)\n> \tGit.xs:62: error: (Each undeclared identifier is reported only once\n> \tGit.xs:62: error: for each function it appears in.)\n> \tmake[1]: *** [Git.o] Error 1\n> \tmake[1]: Leaving directory `/home/torvalds/git/perl'\n> \tmake: *** [all] Error 2\n>\n> I don't like how git now doesn't compile just out of the box on a \n> perfectly regular FC5 box.\n\nEverybody hated the perl crud, so we removed Git.xs and is not\neven part of the source anymore.\n\nThis is a symptom that Git.c leftover from an earlier build was\nin the working tree. Could you try running \"rm -f perl/Git.c\"\nbefore building and see if it helps?\n\nThe sad thing is that we do not ship Git.xs nor generate Git.c\nfrom our Makefile, and while it is nicer to have an entry to\nremove leftover perl/Git.c in our Makefile, it does not really\nhelp in all cases. We discussed this exact issue a few days\nago:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/27730/focus=27853\n"},{"id":"28072","messageId":"Pine.LNX.4.63.0610012052520.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5671","inReplyTo":"Pine.LNX.4.64.0610011132040.3952@g5.osdl.org","subject":"Re: What will happen to git.git in the near future","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-01T18:53:36Z","receivedAt":"2006-10-01T18:53:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 1 Oct 2006, Linus Torvalds wrote:\n\n> \tGit.xs: In function 'XS_Git_xs_version':\n> \tGit.xs:62: error: 'GIT_VERSION' undeclared (first use in this function)\n> \tGit.xs:62: error: (Each undeclared identifier is reported only once\n> \tGit.xs:62: error: for each function it appears in.)\n\nWe had that discussion in another thread already.\n\nJust rm perl/{Git.{bs,c},Makefile} and remake.\n\nCiao,\nDscho\n"},{"id":"28080","messageId":"Pine.LNX.4.64.0610011255030.3952@g5.osdl.org","threadId":"5671","inReplyTo":"7vlknz27qm.fsf@assigned-by-dhcp.cox.net","subject":"Re: What will happen to git.git in the near future","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-01T19:56:28Z","receivedAt":"2006-10-01T19:56:28Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 1 Oct 2006, Junio C Hamano wrote:\n> \n> Everybody hated the perl crud, so we removed Git.xs and is not\n> even part of the source anymore.\n> \n> This is a symptom that Git.c leftover from an earlier build was\n> in the working tree. Could you try running \"rm -f perl/Git.c\"\n> before building and see if it helps?\n\nNope.\n\nThen I just get\n\n\tmake[1]: Entering directory `/home/torvalds/git/perl'\n\tRunning Mkbootstrap for Git ()\n\tchmod 644 Git.bs\n\trm -f blib/arch/auto/Git/Git.so\n\tgcc -shared -L/usr/local/lib Git.o -o blib/arch/auto/Git/Git.so \\\n\t \\\n\t \n\tgcc: Git.o: No such file or directory\n\tgcc: no input files\n\ninstead.\n\nIf that file isn't even supposed to _exist_, then why do we have build \nrules etc crap to do all this? It sounds like the makefiles are broken.\n\n\t\tLinus\n"},{"id":"28081","messageId":"Pine.LNX.4.64.0610011256580.3952@g5.osdl.org","threadId":"5671","inReplyTo":"Pine.LNX.4.63.0610012052520.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: What will happen to git.git in the near future","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-01T19:57:25Z","receivedAt":"2006-10-01T19:57:25Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 1 Oct 2006, Johannes Schindelin wrote:\n> \n> Just rm perl/{Git.{bs,c},Makefile} and remake.\n\nNow this works.\n\nSo somebody tell me why we even invoke that Makefile that shouldn't be \nthere?\n\n\t\tLinus\n"},{"id":"28083","messageId":"Pine.LNX.4.63.0610012208410.14200@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"5671","inReplyTo":"Pine.LNX.4.64.0610011256580.3952@g5.osdl.org","subject":"Re: What will happen to git.git in the near future","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-10-01T20:11:08Z","receivedAt":"2006-10-01T20:11:08Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 1 Oct 2006, Linus Torvalds wrote:\n\n> On Sun, 1 Oct 2006, Johannes Schindelin wrote:\n> > \n> > Just rm perl/{Git.{bs,c},Makefile} and remake.\n> \n> Now this works.\n> \n> So somebody tell me why we even invoke that Makefile that shouldn't be \n> there?\n\nThe problem is that the Makefile does not realize that Git.xs no longer is \nthere. Neither does the code which recreates the Makefile.\n\nYou will notice that there is a new generated perl/Makefile, which no \nlonger tries to compile Git.xs, Git.bs or Git.c\n\nWhen there is a Git.c, \"perl Makefile.PL\" will do the wrong thing, namely \nit expects that you created Git.c by hand, and wants to compile it. If \nthere is a Git.bs, it thinks you want Git.c created.\n\nSort of automake for Perl.\n\nCiao,\nDscho\n"},{"id":"28084","messageId":"Pine.LNX.4.64.0610011318100.3952@g5.osdl.org","threadId":"5671","inReplyTo":"Pine.LNX.4.63.0610012208410.14200@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: What will happen to git.git in the near future","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-10-01T20:23:16Z","receivedAt":"2006-10-01T20:23:16Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 1 Oct 2006, Johannes Schindelin wrote:\n> \n> The problem is that the Makefile does not realize that Git.xs no longer is \n> there. Neither does the code which recreates the Makefile.\n\nNo. The problem is that top-level dependency rules for perl/Makefile are \nsimply _wrong_. It claims it depends on some things (which is true), but \nthen it totally ignores _other_ things that it also depends on.\n\nFurther, even if it was right, the rules to actually _generate_ the \nMakefile then seems wrong, in that it cares about files it shouldn't care \nabout in the first place.\n\nSo why do that at all? Why accept such crap?\n\n\t\t\tLinus\n"}]}