{"thread":{"id":"4365","subject":"What's in git.git (part #2)","startedAt":"2006-06-01T09:19:45Z","lastAt":"2006-06-06T08:19:34Z","messageCount":10,"participants":["Junio C Hamano","Jakub Narebski","Sean","Ryan Anderson","Shawn Pearce","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"21048","messageId":"7v64jli66m.fsf@assigned-by-dhcp.cox.net","threadId":"4365","inReplyTo":null,"subject":"What's in git.git (part #2)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-01T09:19:45Z","receivedAt":"2006-06-01T09:19:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"It's been a while since the last feature release, and I\nthink with the recent \"many things built-in\" (including the\nbusybox style integration) we are nearing a good time to do the\nnext feature release 1.4.0.\n\nBefore doing a 1.4.0-rc1, I would like to see the following\ntopics in the \"next\" branch graduate to \"master\":\n\n - re-add missing flags to format-patch.  I have resurrected\n   \"--signoff\"; if people care about something else we dropped\n   when we went built-in, please raise hand and submit patches.\n\n - tree-parser updates from Linus seems to be fine in the sense\n   I haven't seen breakage from it; I'll push it out to \"master\"\n   before the end of the week.  I'd like to do another round of\n   update to introduce a unified tree/index/directory walker, so\n   settling this down is sort of urgent.\n\n - http-fetch fixes from Nick, which looked obviously correct.\n   I would appreciate test reports from people who saw breakages\n   on this one.\n\n - reflog from Shawn.  Do people find this useful?  I've enabled\n   reflog on \"next\" branch in my development repository to see\n   how useful it would be for myself a few days ago, and also in\n   a linux-2.6 repository I use for testing (I do not hack on\n   kernel myself).  \n\nOther topics in \"next\" includes:\n\n - read/write-tree --prefix.  This is remnant of now-vetoed\n   subproject support using \"bind commit\".  I kept both of them\n   because they could be useful independent of \"bind commit\",\n   but I do not know how much.  I think read-tree --prefix might\n   probably be more useful than write-tree --prefix, since the\n   latter can be writing out the whole tree and run rev-parse\n   $tree:/path/name to extract that part, but the former does\n   not have an easy equivalent (you could pipe ls-tree output to\n   sed and pipe that to update-cache --index-info, but that is\n   crumsy). \n\n   I'd like to do \"gitlink\" based subproject support but most\n   likely that needs to come after tree/index/directory walker.\n\n - fetch-pack client-side hack.  When your repository has more\n   roots than the repository you are fetching from, the common\n   commit discovery exchange between fetch-pack and upload-pack\n   ends up traversing down the ancestry chain of the history the\n   other end do not have.  The hack in the \"next\" branch is to\n   give up the common commit discovery early on the client side,\n   which Ralf Baechle who originally reported the problem says\n   to fix the problem (<20060526154239.GA20839@linux-mips.org>);\n   but the proper fix involves a bit smarter upload-pack.\n\n   I've posted a hacky upload-pack patch:\n   \n\t<7vfyiwi4xl.fsf@assigned-by-dhcp.cox.net>\n\n   but I think it should really needs to be cleaned up properly.\n\n\nThings that we might want to have in 1.4.0 but not even in \"next\"\nyet include:\n\n - p4 importer (Sean Estabrooks) -- are people interested?\n\n - letting fetch-pack to ask for an arbitrary commit object the\n   user obtained out of band (Eric W Biederman) -- waiting for\n   updated patch.  We would need a corresponding one-liner patch\n   to upload-pack when we do this.\n\n - using ~/.gitrc to give a fall-back default when\n   $GIT_DIR/config does not have values.\n\n - command aliases and possibly default arguments via the\n   configuration file.\n"},{"id":"21050","messageId":"7v1wu9i608.fsf@assigned-by-dhcp.cox.net","threadId":"4365","inReplyTo":"7v64jli66m.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (part #2)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-01T09:23:35Z","receivedAt":"2006-06-01T09:23:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <junkio@cox.net> writes:\n\n> It's been a while since the last feature release,...\n\nSo apparently somehow part #1 (the regular \"master has these\",\n\"next in addition has these\" message I occasionally do) is not\nliked by the mailing list.  I wonder what's in it that makes it\ndropped on the floor...\n"},{"id":"21053","messageId":"e5mc5n$m33$1@sea.gmane.org","threadId":"4365","inReplyTo":"7v1wu9i608.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (part #2)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-06-01T09:31:49Z","receivedAt":"2006-06-01T09:31:49Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Junio C Hamano <junkio@cox.net> writes:\n> \n>> It's been a while since the last feature release,...\n> \n> So apparently somehow part #1 (the regular \"master has these\",\n> \"next in addition has these\" message I occasionally do) is not\n> liked by the mailing list.  I wonder what's in it that makes it\n> dropped on the floor...\n\nI had same problem (message not appearing on list), and as far as \nI was able to analyse it was because message accidentally (via unclean\ncopy'n'paste) had some unusual characters.\n\n-- \nJakub Narebski\nWarsaw, Poland\n"},{"id":"21056","messageId":"BAYC1-PASMTP03700A0D31613228040FADAE900@CEZ.ICE","threadId":"4365","inReplyTo":"7v64jli66m.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (part #2)","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-06-01T11:26:37Z","receivedAt":"2006-06-01T11:26:37Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 01 Jun 2006 02:19:45 -0700\nJunio C Hamano <junkio@cox.net> wrote:\n\n>  - p4 importer (Sean Estabrooks) -- are people interested?\n\nJunio,\n\nThere just won't be anywhere near the call for this as there is\nfor the cvs and svn importers.  Even so, a few people have expressed\ninterest and it has been used by the Sourcemage folks with some success.\nWould you consider carrying this in contrib just so it has a home?\n\nSean\n"},{"id":"21066","messageId":"20060601225152.GG32457@h4x0r5.com","threadId":"4365","inReplyTo":"7v64jli66m.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (part #2)","fromName":"Ryan Anderson","fromEmail":"ryan@michonline.com","sentAt":"2006-06-01T22:51:54Z","receivedAt":"2006-06-01T22:51:54Z","isPatch":false,"sender":{"key":"ryan@michonline.com","avatar":null},"body":"On Thu, Jun 01, 2006 at 02:19:45AM -0700, Junio C Hamano wrote:\n> Things that we might want to have in 1.4.0 but not even in \"next\"\n> yet include:\n> \n>  - p4 importer (Sean Estabrooks) -- are people interested?\n\nI think adding more importers is a good thing.  There's no sense in\nhaving people reinvent the wheel.\n\nWhich reminds me, I need to polish and send off my BitKeeper importer.\n(It's slow and dumb, but works.)\n"},{"id":"21076","messageId":"20060602023545.GA5039@spearce.org","threadId":"4365","inReplyTo":"7v64jli66m.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (part #2)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-06-02T02:35:45Z","receivedAt":"2006-06-02T02:35:45Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano <junkio@cox.net> wrote:\n>  - reflog from Shawn.  Do people find this useful?  I've enabled\n>    reflog on \"next\" branch in my development repository to see\n>    how useful it would be for myself a few days ago, and also in\n>    a linux-2.6 repository I use for testing (I do not hack on\n>    kernel myself).  \n\nI find it useful to track what I've sent to you just in case I\nscrew up some ref somewhere.  I like knowing that if I perform a\nbad update-ref call (which I'm prone to do sometimes) that I can\nrecover quickly as the log exists.\n\nNot having that prior ref value was about the only area of `possible\ndata loss' that I've every really noticed with GIT.  Well, that and\nonly having one repository holding all of your important files and\nyou rm -rf the dang directory by accident one day...  but that's\njust foolishness on the user's part.  :-)\n\n>  - using ~/.gitrc to give a fall-back default when\n>    $GIT_DIR/config does not have values.\n> \n>  - command aliases and possibly default arguments via the\n>    configuration file.\n\nI'm certainly interested in these two - and I don't think I'm alone\nwhen I say that.  :-)\n\n-- \nShawn.\n"},{"id":"21091","messageId":"7v3beodpqs.fsf@assigned-by-dhcp.cox.net","threadId":"4365","inReplyTo":"20060602023545.GA5039@spearce.org","subject":"Re: What's in git.git (part #2)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-02T06:40:43Z","receivedAt":"2006-06-02T06:40:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce <spearce@spearce.org> writes:\n\n> I find it useful to track what I've sent to you just in case I\n> screw up some ref somewhere.  I like knowing that if I perform a\n> bad update-ref call (which I'm prone to do sometimes) that I can\n> recover quickly as the log exists.\n\nI find it interesting to be able to say:\n\n\t$ git log next@{yesterday}..next\n\nI often find myself getting curious to see:\n\n\t$ git reflog next\n        Wed May 31 14:23:58 2006 -0700\n                62b693a... Merge branch 'master' into next\n        Wed May 31 14:26:39 2006 -0700\n                422dfaf... Merge branch 'lt/tree-2' into next\n        Wed May 31 15:14:58 2006 -0700\n                100c25f... Merge branch 'ff/svnimport' into next\n        Wed May 31 15:23:54 2006 -0700\n                a25963b... Merge branch 'jc/fmt-patch' into next\n        ...\n\nThe latter is probably not so useful in practice -- I suspect\nthat I would want to see such a list only while I am interested\nin how well reflog works.\n"},{"id":"21303","messageId":"20060606053905.GA9797@spearce.org","threadId":"4365","inReplyTo":"7v3beodpqs.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git (part #2)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-06-06T05:39:05Z","receivedAt":"2006-06-06T05:39:05Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> Shawn Pearce <spearce@spearce.org> writes:\n> \n> > I find it useful to track what I've sent to you just in case I\n> > screw up some ref somewhere.  I like knowing that if I perform a\n> > bad update-ref call (which I'm prone to do sometimes) that I can\n> > recover quickly as the log exists.\n> \n> I find it interesting to be able to say:\n> \n> \t$ git log next@{yesterday}..next\n> \n> I often find myself getting curious to see:\n> \n> \t$ git reflog next\n>         Wed May 31 14:23:58 2006 -0700\n>                 62b693a... Merge branch 'master' into next\n>         ...\n\nHmm, looks like nobody has actually implemented that - at least not\nin 'next'.  :-)\n\nIs that a serious feature request?  If so I'll do it.  BTW: we're\nalso still lacking reflog during receive-pack.  Much of the update()\nfunction in receive-pack.c can be replaced with the new locking\nfunctions, except that if reflog is enabled on the target ref then\nGIT_COMMITTER_NAME and GIT_COMMITTER_EMAIL need to be set for the\nupdate to succeed.\n\nI've been busy at work but I really have been wanting to put\nsome time into this GIT Eclipse plugin that I've been neglecting.\nSome folks at work are starting to become more interested in it.\nI have gotten the really core functionality done; all that is\nleft is the hard stuff (directory synchronization, push, fetch,\nnon-delta pack generation for push[1], tree diff).\n\n\n*1* Generating a simple pack with only deflate compression on the\nobjects should be trivial.  Since this is 100% pure Java code nobody\nshould be expecting great performance out of it from day 1 anyway.\nSure its not an optimal transport but if you were that worried about\nthe transfer byte costs to push then you probably would just prefer\nto use the native tools code tools anyway.\n\n-- \nShawn.\n"},{"id":"21306","messageId":"7vhd2yzu3x.fsf@assigned-by-dhcp.cox.net","threadId":"4365","inReplyTo":"20060606053905.GA9797@spearce.org","subject":"Re: What's in git.git (part #2)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-06T06:16:50Z","receivedAt":"2006-06-06T06:16:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce <spearce@spearce.org> writes:\n\n>> I find it interesting to be able to say:\n>> \n>> \t$ git log next@{yesterday}..next\n>> \n>> I often find myself getting curious to see:\n>> \n>> \t$ git reflog next\n>>         Wed May 31 14:23:58 2006 -0700\n>>                 62b693a... Merge branch 'master' into next\n>>         ...\n>\n> Hmm, looks like nobody has actually implemented that - at least not\n> in 'next'.  :-)\n>\n> Is that a serious feature request?\n\nI've written it but it was so trivial I threw it away after\nwriting the e-mail you are responding to with it.\n\nAs I said, I _think_ I was interested in seeing it primarily\nbecause reflog was a new curiosity to me.  It is more like\nwanting to know how the new tool works more than using the new\ntool effectively to improve my productivity.  In a \"serious\"\nenvironment, a tool is just something you would use to get the\nreal job done, not to toy around to see how _it_ works, so I\nsuspect the above would not be so useful in practice, as I wrote\nin the message.\n"},{"id":"21309","messageId":"Pine.LNX.4.63.0606061016150.11478@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"4365","inReplyTo":"20060606053905.GA9797@spearce.org","subject":"Re: What's in git.git (part #2)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-06-06T08:19:34Z","receivedAt":"2006-06-06T08:19:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 6 Jun 2006, Shawn Pearce wrote:\n\n> *1* Generating a simple pack with only deflate compression on the\n> objects should be trivial.  Since this is 100% pure Java code nobody\n> should be expecting great performance out of it from day 1 anyway.\n\nIf you use jzlib (http://www.jcraft.com/jzlib/) it should not be slow. \nIMHO the I/O will be the bottleneck, but I would be happy to be \ncontradicted by the facts.\n\nCiao,\nDscho\n"}]}