{"thread":{"id":"26360","subject":"Features from GitSurvey 2010","startedAt":"2011-01-29T10:01:46Z","lastAt":"2011-02-03T21:38:30Z","messageCount":36,"participants":["Dmitry S. Kravtsov","Jonathan Nieder","Jakub Narebski","Nguyen Thai Ngoc Duy","Shawn Pearce","Matthieu Moy","Ilari Liusvaara","Junio C Hamano","Nicolas Pitre","david@lang.hm","Kevin P. Fleming","Geert Bosch"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"160022","messageId":"AANLkTi=gf9_618iojpYJgN_msAe-FBq-Jao=sj76VQak@mail.gmail.com","threadId":"26360","inReplyTo":null,"subject":"Features from GitSurvey 2010","fromName":"Dmitry S. Kravtsov","fromEmail":"idkravitz@gmail.com","sentAt":"2011-01-29T10:01:46Z","receivedAt":"2011-01-29T10:01:46Z","isPatch":false,"sender":{"key":"idkravitz@gmail.com","avatar":"https://gravatar.com/avatar/6f2f8e0e5eb02e84138927ffb9b2edbc750b4c44cab9270bdc01bd318d8783da?d=mp&s=160"},"body":"Hello,\n\nI want to dedicate my coursework at University to implementation of\nsome useful git feature. So I'm interesting in some kind of list of\ndevelopment status of these features\nhttps://git.wiki.kernel.org/index.php/GitSurvey2010#17._Which_of_the_following_features_would_you_like_to_see_implemented_in_git.3F\n\nOr I'll be glad to know what features are now 'free' and what are\ncurrently in active development.\n\nBest Regards\n-- \nDmitry S. Kravtsov\n"},{"id":"160039","messageId":"20110129231310.GA11088@burratino","threadId":"26360","inReplyTo":"AANLkTi=gf9_618iojpYJgN_msAe-FBq-Jao=sj76VQak@mail.gmail.com","subject":"Re: Features from GitSurvey 2010","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-01-29T23:13:10Z","receivedAt":"2011-01-29T23:13:10Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Dmitry,\n\nDmitry S. Kravtsov wrote:\n\n> I want to dedicate my coursework at University to implementation of\n> some useful git feature. So I'm interesting in some kind of list of\n> development status of these features\n[...]\n> Or I'll be glad to know what features are now 'free' and what are\n> currently in active development.\n\nInteresting question.  The short answer is that they are all \"free\".\nGenerally people seem to be happy to learn of an alternative approach\nto what they have been working on.\n\n[For the following pointers, the easiest way to follow up is probably\nto search the mailing list archives.]\n\n> better support for big files (large media)\n\nFor a conservative approach, you might want to get in touch with Sam\nHocevar, Nicolas Pitre, and Miklos Vajna.  The idea is to stream big\nfiles directly to pack and not waste time trying to compress them.\n\nFor an alternative approach, Joey Hess's git-annex might be\ninteresting.\n\n> resumable clone/fetch (and other remote operations)\n\nJakub Narebski seems to be interested in this and Nicolas Pitre has\ngiven some good advice about it.  You can get something usable today\nby putting up a git bundle for download over HTTP or rsync, so it is\npossible that this just involves some UI (porcelain) and documentation\nwork to become standard practice.\n \n> GitTorrent Protocol, or git-mirror\n\nSam Vilain and Jonas Fonseca did some good work on this, but it's\nstalled.\n \n> lazy clone / on-demand fetching of object\n\nThere's a patch.  As is, it is not likely to be useful outside\nspecialized circumstances imho.\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/73117\n \n> subtree clone\n\nNguyễn Thái Ngọc Duy and Elijah Newren have done some design and\nprototyping work.\n \n> support for tracking empty directories\n\nTricky to get the UI right.  I am interested in and would be glad to\nhelp with this one.\n \n> environment variables in config\n> better undo/abort/continue, and for more commands\n\nThese might involve nice \"bite-sized\" projects.  Christian Couder\nand Johannes Schindelin have discussed cherry-pick --abort/--continue\nand they might be interested in patches on that subject.  Stephen\nBeyer's sequencer might be interesting for inspiration:\n\ngit://repo.or.cz/git/sbeyer.git\n\n> '-n' like option for each command, which describes what would happen\n> warn before/when rewriting published history\n> git push --create\n> \"commands issued\" (or \"command equivalents\") in git-gui / gitk\n\nGo for it.  \"git init --remote\" might be a good companion to \"git push\n--create\".\n \n> side-by-side diffs and/or color-words diff in gitweb\n> admin and/or write features in gitweb\n> graphical history view in gitweb\n \nThere may or may not have been design work on some of these for Pavan\nKumar Sunkara's last summer of code project.  John 'Warthog9' Hawley,\nJakub Narebski, and Petr Baudis might have advice.\n\n> GUI for rebase in git-gui\n> GUI for creating repository in git-gui\n> graphical diff/merge tool integrated with git-gui\n> syntax highlighting in git-gui\n \nPat Thoyts is probably the one to talk to.\n\n> filename encoding (in repository vs in filesystem)\n \nThis is important for the Windows port and likely to be a nuisance\non Unix.  I think there has been some work on it on the msysgit list?\n\n> localization of command-line messages (i18n)\n\nÆvar Arnfjörð Bjarmason did some work which is in pu.  It needs\nsome polishing.  I am also interested.\n \n> wholesame directory rename detection\n\nYann Dirson wrote a patch.  It needs some polishing (I'd be glad to\nhelp --- it would be exciting to see this move forward).\n \n> union checkouts (some files from one branch, some from other)\n\nNot sure I understand the use case?\n \n> advisory locking / \"this file is being edited\"\n\nProbably better to implement out of band (using hooks?).  I don't\nknow of any work or documentation in that direction.\n \n> built-in gitjour/bananajour support\n \nA good start might be to submit one or both of these to contrib?\n\n> better support for submodules\t\n\nJens Lehmann has done some great work on this and presumably would\nbe happy for help.\n\nhttps://github.com/jlehmann/git-submod-enhancements/wiki\n\nHope that helps,\nJonathan\n"},{"id":"160166","messageId":"201102011451.17456.jnareb@gmail.com","threadId":"26360","inReplyTo":"20110129231310.GA11088@burratino","subject":"Re: Features from GitSurvey 2010","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-02-01T13:51:15Z","receivedAt":"2011-02-01T13:51:15Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, 30 Jan 2011, Jonathan Nieder wrote:\n> Hi Dmitry,\n> \n> Dmitry S. Kravtsov wrote:\n> \n> > I want to dedicate my coursework at University to implementation of\n> > some useful git feature. So I'm interesting in some kind of list of\n> > development status of these features\n> [...]\n> > Or I'll be glad to know what features are now 'free' and what are\n> > currently in active development.\n> \n> Interesting question.  The short answer is that they are all \"free\".\n> Generally people seem to be happy to learn of an alternative approach\n> to what they have been working on.\n> \n> [For the following pointers, the easiest way to follow up is probably\n> to search the mailing list archives.]\n> \n> > better support for big files (large media)\n> \n> For a conservative approach, you might want to get in touch with Sam\n> Hocevar, Nicolas Pitre, and Miklos Vajna.  The idea is to stream big\n> files directly to pack and not waste time trying to compress them.\n\nThere is also, supposedly stalled, git-bigfiles project.\n\n> \n> For an alternative approach, Joey Hess's git-annex might be\n> interesting.\n\nNote that this feature would not be easy to implement; you would need\nboth quite good knowledge of git internals, and some realistic use case\nthat you can test performance of your improvements with.\n\n> > resumable clone/fetch (and other remote operations)\n> \n> Jakub Narebski seems to be interested in this and Nicolas Pitre has\n> given some good advice about it.  You can get something usable today\n> by putting up a git bundle for download over HTTP or rsync, so it is\n> possible that this just involves some UI (porcelain) and documentation\n> work to become standard practice.\n\nI wouldn't say that: it is Nicolas Pitre (IIRC) who was doing the work;\nI was only interested party posting comments, but no code.\n\nAgain, this feature is not very easy to implement, and would require \nknowledge of git internals including \"smart\" git transport (\"Pro Git\"\nbook can help there).\n\n> > GitTorrent Protocol, or git-mirror\n> \n> Sam Vilain and Jonas Fonseca did some good work on this, but it's\n> stalled.\n\nThere was some recent discussion on this on git mailing llist, but\nwithout any code.\n\nOne would need to know similar areas as for \"resumable clone\" feature.\nPlus some knowledge on P2P transport in GitTorrent case.\n\n> > lazy clone / on-demand fetching of object\n> \n> There's a patch.  As is, it is not likely to be useful outside\n> specialized circumstances imho.\n> \n> http://thread.gmane.org/gmane.comp.version-control.git/73117\n\nOne would need to know about how git checks for consistency, e.g. via\ngit-fsck for that.\n\n> > subtree clone\n> \n> Nguyễn Thái Ngọc Duy and Elijah Newren have done some design and\n> prototyping work.\n\nGit mailing list archives should contain proof of concept / RFC patches\nfor this feature.  Quite interesting.\n\n> > support for tracking empty directories\n> \n> Tricky to get the UI right.  I am interested in and would be glad to\n> help with this one.\n\nAlso one needs to remember that this would require adding extension\nto git index, because currently it tracks only files, and not \ndirectories.  Explicitly tracking directories in the index could be \nuseful for other purposes...\n\nThe major difficulty of this is IMHO not the UI, but tracking all those\ntricky corner cases (like directory/file conflict, etc.).\n\n[...] \n> > side-by-side diffs and/or color-words diff in gitweb\n> > admin and/or write features in gitweb\n> > graphical history view in gitweb\n>  \n> There may or may not have been design work on some of these for Pavan\n> Kumar Sunkara's last summer of code project.  John 'Warthog9' Hawley,\n> Jakub Narebski, and Petr Baudis might have advice.\n\nPavan was to work on admin and/or write features in gitweb, while he\ndidn't even finish splitting gitweb (perhaps he tried to be too \nambitious in trying to split whole of gitweb at once, instead of \nsplitting-off well definied pieces?).\n\nThere are existing Perl modules on CPAN and/or Perl web apps that use\nside-by-side diffs and/or color-words diff, so there is code to take an\nexample, to use in gitweb, or to borrow.\n\nThe graphical history view would be more difficult, but not very \ndifficult, I think.  You would have to decide how to draw a graph: \nshould gitweb generate image on the fly, use some smart combination\nof CSS and pre-made images (perhaps with transparency), use Unicode\ngraph characters, or use ASCII-art graph.  You would also have to decide \nwhether to use or base on some existing algorithm to generate graph,\nborrowing from tig, git-browser, gitk or git-forest (the last is in \nPerl, like gitweb), or whether to make use of \"git log --graph\" output.\n\n> > GUI for rebase in git-gui\n> > GUI for creating repository in git-gui\n> > graphical diff/merge tool integrated with git-gui\n> > syntax highlighting in git-gui\n>  \n> Pat Thoyts is probably the one to talk to.\n\nNote that for graphical diff/merge tool you should be able to borrow \nfrom xxdiff graphical diff/merge tool, which is also written in Tcl/Tk.\n\n> > filename encoding (in repository vs in filesystem)\n>  \n> This is important for the Windows port and likely to be a nuisance\n> on Unix.  I think there has been some work on it on the msysgit list?\n\nThat would need a good design (note also different forms of Unicode),\nand overcoming inertia.\n\n> > localization of command-line messages (i18n)\n> \n> Ævar Arnfjörð Bjarmason did some work which is in pu.  It needs\n> some polishing.  I am also interested.\n\nI don't know how much is left to do (beside actually translating \nmessages).  But this series could use a little help.\n  \n> > union checkouts (some files from one branch, some from other)\n> \n> Not sure I understand the use case?\n\nI don't know if it would be really useful, but the concept is similar to \nunion mounts.  In union mount (unionfs, aufs,...) you can e.g. mount \nCD-ROM read-only, and over it overlay on some read-write filesystem.\n\nThe idea is to have some files (some directories) in working area come \nfrom one branch, some from other branch, persistently in some way.  Not \nsure if it would be actually useful.\n  \n> > advisory locking / \"this file is being edited\"\n> \n> Probably better to implement out of band (using hooks?).  I don't\n> know of any work or documentation in that direction.\n\nYes, t would probably be best as external project, only with git \nintegration.\n\n> > built-in gitjour/bananajour support\n>  \n> A good start might be to submit one or both of these to contrib?\n\nIf I remember correctly there are some third-party extensions to be \nfound, and perhaps even some patches in git mailing list.\n\n\nBest choose something you are both interested in, and proficient with.\n\nHTH\n-- \nJakub Narebski\nPoland\n"},{"id":"160181","messageId":"AANLkTinJVa++tttPDav1g1+w128fWsouM=+gf14eUOOK@mail.gmail.com","threadId":"26360","inReplyTo":"201102011451.17456.jnareb@gmail.com","subject":"Re: Features from GitSurvey 2010","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-01T15:52:34Z","receivedAt":"2011-02-01T15:52:34Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Feb 1, 2011 at 8:51 PM, Jakub Narebski <jnareb@gmail.com> wrote:\n> On Sun, 30 Jan 2011, Jonathan Nieder wrote:\n>> > support for tracking empty directories\n>>\n>> Tricky to get the UI right.  I am interested in and would be glad to\n>> help with this one.\n>\n> Also one needs to remember that this would require adding extension\n> to git index, because currently it tracks only files, and not\n> directories.  Explicitly tracking directories in the index could be\n> useful for other purposes...\n>\n> The major difficulty of this is IMHO not the UI, but tracking all those\n> tricky corner cases (like directory/file conflict, etc.).\n\nSort order in index is quite special/strange and must be handled\ncorrectly when dirs and files are mixed. There are already special\ndirectories in index: the submodules. Current git code treats\nS_ISDIR() and S_ISGITLINK() the same in ce_to_dtype() and some more\nplaces. You need to decouple it somehow.\n\nI tried this (for another purpose) and pulled back. I recall Shawn had\na tree-based index implementation, don't know if he still has it.\nCould be a good point to start adding dirs to index.\n\nActually tree-based index with dictionary (something like trees in\npackv4) is a good feature itself. It could shrink index size down a\nlot. index is frequently read/written so small index helps (webkit's\nindex is 16M, 4M after gzipped).\n-- \nDuy\n"},{"id":"160185","messageId":"AANLkTinPAL2rEUMe-tRGFxSQ0-gfAJvSO7WW+f+2Fd2u@mail.gmail.com","threadId":"26360","inReplyTo":"201102011451.17456.jnareb@gmail.com","subject":"Re: Features from GitSurvey 2010","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2011-02-01T16:27:31Z","receivedAt":"2011-02-01T16:27:31Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Tue, Feb 1, 2011 at 05:51, Jakub Narebski <jnareb@gmail.com> wrote:\n>\n>> > resumable clone/fetch (and other remote operations)\n>>\n>> Jakub Narebski seems to be interested in this and Nicolas Pitre has\n>> given some good advice about it.  You can get something usable today\n>> by putting up a git bundle for download over HTTP or rsync, so it is\n>> possible that this just involves some UI (porcelain) and documentation\n>> work to become standard practice.\n>\n> I wouldn't say that: it is Nicolas Pitre (IIRC) who was doing the work;\n> I was only interested party posting comments, but no code.\n>\n> Again, this feature is not very easy to implement, and would require\n> knowledge of git internals including \"smart\" git transport (\"Pro Git\"\n> book can help there).\n\nI think Nico and I have mostly solved this with the pack caching idea.\n If we cache the pack file, we can resume anywhere in about 97% of the\ntransfer.  The first 3% cannot be resumed easily, its back to the old\n\"git cannot be resumed\" issue.  Fixing that last 3% is incredibly\ndifficult... but resuming within the remaining 97% is a pretty simple\nextension of the protocol.  The hard part is the client side\ninfrastructure to remember where we left off and restart.\n\n>> > GitTorrent Protocol, or git-mirror\n>>\n>> Sam Vilain and Jonas Fonseca did some good work on this, but it's\n>> stalled.\n>\n> There was some recent discussion on this on git mailing llist, but\n> without any code.\n>\n> One would need to know similar areas as for \"resumable clone\" feature.\n> Plus some knowledge on P2P transport in GitTorrent case.\n\nI think this is very similar to resumable clone.  With the cached\npack, clients could use torrent to find it.  But right now Nico and I\nare sort of expecting a cached pack to live for about the release\ncycle of a project... e.g. only a couple of months.  I don't know if\nthat can be seeded fast enough on P2P networks to make it useful to\ntorrent the ~97% of the project that is the cached pack during an\ninitial clone request.\n\n>> > subtree clone\n>>\n>> Nguyễn Thái Ngọc Duy and Elijah Newren have done some design and\n>> prototyping work.\n>\n> Git mailing list archives should contain proof of concept / RFC patches\n> for this feature.  Quite interesting.\n\nI think Junio has already started thinking about this one.\n\n-- \nShawn.\n"},{"id":"160184","messageId":"AANLkTikri2A_WqSB1nd=SZ5NZR6hbsxSy-ziYVcPUSxy@mail.gmail.com","threadId":"26360","inReplyTo":"AANLkTinJVa++tttPDav1g1+w128fWsouM=+gf14eUOOK@mail.gmail.com","subject":"Re: Features from GitSurvey 2010","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2011-02-01T16:33:53Z","receivedAt":"2011-02-01T16:33:53Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Tue, Feb 1, 2011 at 07:52, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:\n> On Tue, Feb 1, 2011 at 8:51 PM, Jakub Narebski <jnareb@gmail.com> wrote:\n>> On Sun, 30 Jan 2011, Jonathan Nieder wrote:\n>>> > support for tracking empty directories\n>>>\n>>> Tricky to get the UI right.  I am interested in and would be glad to\n>>> help with this one.\n>>\n>> Also one needs to remember that this would require adding extension\n>> to git index, because currently it tracks only files, and not\n>> directories.  Explicitly tracking directories in the index could be\n>> useful for other purposes...\n>>\n>> The major difficulty of this is IMHO not the UI, but tracking all those\n>> tricky corner cases (like directory/file conflict, etc.).\n>\n> Sort order in index is quite special/strange and must be handled\n> correctly when dirs and files are mixed.\n\nIts not the order in the index that is confusing, its the order in the\ntree objects.  The index sort order is simple, since every path is a\nfull path string from the top of the repository... you use strcmp() to\norder them into a natural order.  This however skews where a\nsubdirectory should live relative to a sibling file, because the\n\"subdirectory\" sorts as though its name ends with '/'.\n\n> There are already special\n> directories in index: the submodules. Current git code treats\n> S_ISDIR() and S_ISGITLINK() the same in ce_to_dtype() and some more\n> places. You need to decouple it somehow.\n\nMore confusingly, the GITLINK type is handled as though its *not* a\ndirectory.  Storing an empty directory probably means tracking it like\na real directory, but using the empty tree SHA-1 as its value.\nOtherwise we probably have all sorts of stuff broken.\n\n> I tried this (for another purpose) and pulled back. I recall Shawn had\n> a tree-based index implementation, don't know if he still has it.\n\nNo, we threw out the tree-based index that was used inside of EGit\nyears ago.  It turned out to be a horrible idea because it wasn't\ncompatible with the C tools, and it didn't have the inode stat cache\nto tell us which files were clean or dirty quickly.\n\n> Actually tree-based index with dictionary (something like trees in\n> packv4) is a good feature itself. It could shrink index size down a\n> lot. index is frequently read/written so small index helps (webkit's\n> index is 16M, 4M after gzipped).\n\nI think a lot of the reason the webkit index is 16M, gzip to 4M is\nbecause of the duplicate path prefixes that appear on all files within\nthe same directory.  If the index was still a single file, but was\norganized into sections by tree (like the TREE extension within the\nindex itself) you could avoid having the full path within the index\nfile and save a lot of space when there are many files within\nsubdirectories.  But this does complicate the C code because you would\nneed to copy each of those path segments together into a path buffer\nin order to access the file in the working tree.\n\nIts probably faster to copy those path segments on read into a big\npath buffer, and break them apart on write, than to have a huge index\nfile.  We already reformat the index during reading/writing to expand\nsome of the fields for in-memory only flags.\n\n-- \nShawn.\n"},{"id":"160191","messageId":"AANLkTi=oTL2_ObcyKRb7bf7ZMPZoa1BU7uNH5pJRQtVC@mail.gmail.com","threadId":"26360","inReplyTo":"AANLkTinPAL2rEUMe-tRGFxSQ0-gfAJvSO7WW+f+2Fd2u@mail.gmail.com","subject":"Re: Features from GitSurvey 2010","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-01T17:05:55Z","receivedAt":"2011-02-01T17:05:55Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Feb 1, 2011 at 11:27 PM, Shawn Pearce <spearce@spearce.org> wrote:\n>>> > subtree clone\n>>>\n>>> Nguyễn Thái Ngọc Duy and Elijah Newren have done some design and\n>>> prototyping work.\n>>\n>> Git mailing list archives should contain proof of concept / RFC patches\n>> for this feature.  Quite interesting.\n>\n> I think Junio has already started thinking about this one.\n\nI need to get nd/pathspec right and implement negative pathspecs\nbefore returning to this feature. But there are still interesting\nissues:\n\n - narrow by directories or pathspecs (or unpack_trees() by\ndirectories or pathspecs)\n - widen a clone (negative pathspecs should help calculating necessary objects)\n - should commit objects that does not update narrow area be fetched\n(I recall it consumes a considerable amount. Security is also an\nissue)\n - push support for shallow clone (Elijah approach does not base on\nshallow clone, so it's non-issue)\n-- \nDuy\n"},{"id":"160192","messageId":"AANLkTi=_DPSp2P3MuFOPgua2nH7U+RUt4AfAHSyPVv-G@mail.gmail.com","threadId":"26360","inReplyTo":"AANLkTinPAL2rEUMe-tRGFxSQ0-gfAJvSO7WW+f+2Fd2u@mail.gmail.com","subject":"Re: Features from GitSurvey 2010","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-01T17:11:56Z","receivedAt":"2011-02-01T17:11:56Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Tue, Feb 1, 2011 at 11:27 PM, Shawn Pearce <spearce@spearce.org> wrote:\n> On Tue, Feb 1, 2011 at 05:51, Jakub Narebski <jnareb@gmail.com> wrote:\n>>\n>>> > resumable clone/fetch (and other remote operations)\n>>>\n>>> Jakub Narebski seems to be interested in this and Nicolas Pitre has\n>>> given some good advice about it.  You can get something usable today\n>>> by putting up a git bundle for download over HTTP or rsync, so it is\n>>> possible that this just involves some UI (porcelain) and documentation\n>>> work to become standard practice.\n>>\n>> I wouldn't say that: it is Nicolas Pitre (IIRC) who was doing the work;\n>> I was only interested party posting comments, but no code.\n>>\n>> Again, this feature is not very easy to implement, and would require\n>> knowledge of git internals including \"smart\" git transport (\"Pro Git\"\n>> book can help there).\n>\n> I think Nico and I have mostly solved this with the pack caching idea.\n>  If we cache the pack file, we can resume anywhere in about 97% of the\n> transfer.  The first 3% cannot be resumed easily, its back to the old\n> \"git cannot be resumed\" issue.  Fixing that last 3% is incredibly\n\nI thought the cached pack contained anything and for initial clone, we\nsimply send the pack. What is this 3%? Commit list? Initial commit?\n\n> difficult... but resuming within the remaining 97% is a pretty simple\n> extension of the protocol.  The hard part is the client side\n> infrastructure to remember where we left off and restart.\n\nNarrow/Subtree clone is still just an idea, but can pack cache support\nbe made to resumable initial narrow clone too?\n-- \nDuy\n"},{"id":"160193","messageId":"20110201172835.GA3771@burratino","threadId":"26360","inReplyTo":"201102011451.17456.jnareb@gmail.com","subject":"Tracking empty directories","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-01T17:28:35Z","receivedAt":"2011-02-01T17:28:35Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jakub Narebski wrote:\n\n> Also one needs to remember that this would require adding extension\n> to git index, because currently it tracks only files, and not \n> directories.  Explicitly tracking directories in the index could be \n> useful for other purposes...\n>\n> The major difficulty of this is IMHO not the UI, but tracking all those\n> tricky corner cases (like directory/file conflict, etc.).\n\nI have ideas about how to resolve those tricky corner cases, but not\nabout what the UI should look like.  How does one go about adding a\ndirectory?  Does it ever get implicitly removed?\n\nWould this actually require an index extension, strictly speaking?\nCertainly one ought to register an extension name or bump the version\nnumber to avoid confusing gits that don't know about the feature.\nBut after that, couldn't we (e.g.) allow the directory name (ending\nwith '/') as index entry?\n\nA related question is backward compatibility (both for alternative git\nimplementations and for scripts that did not know that \"git ls-files\"\nmight mention an empty directory) which somehow seems less\ndaunting. ;-)\n\nJonathan\n"},{"id":"160194","messageId":"AANLkTi=KUpYJBRMp9ti0h+g6a0iTw4D113rTgfTpR8C4@mail.gmail.com","threadId":"26360","inReplyTo":"AANLkTi=_DPSp2P3MuFOPgua2nH7U+RUt4AfAHSyPVv-G@mail.gmail.com","subject":"Re: Features from GitSurvey 2010","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2011-02-01T17:34:40Z","receivedAt":"2011-02-01T17:34:40Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Tue, Feb 1, 2011 at 09:11, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:\n> On Tue, Feb 1, 2011 at 11:27 PM, Shawn Pearce <spearce@spearce.org> wrote:\n>> On Tue, Feb 1, 2011 at 05:51, Jakub Narebski <jnareb@gmail.com> wrote:\n>>>\n>>>> > resumable clone/fetch (and other remote operations)\n>>>>\n>>>> Jakub Narebski seems to be interested in this and Nicolas Pitre has\n>>>> given some good advice about it.  You can get something usable today\n>>>> by putting up a git bundle for download over HTTP or rsync, so it is\n>>>> possible that this just involves some UI (porcelain) and documentation\n>>>> work to become standard practice.\n>>>\n>>> I wouldn't say that: it is Nicolas Pitre (IIRC) who was doing the work;\n>>> I was only interested party posting comments, but no code.\n>>>\n>>> Again, this feature is not very easy to implement, and would require\n>>> knowledge of git internals including \"smart\" git transport (\"Pro Git\"\n>>> book can help there).\n>>\n>> I think Nico and I have mostly solved this with the pack caching idea.\n>>  If we cache the pack file, we can resume anywhere in about 97% of the\n>> transfer.  The first 3% cannot be resumed easily, its back to the old\n>> \"git cannot be resumed\" issue.  Fixing that last 3% is incredibly\n>\n> I thought the cached pack contained anything and for initial clone, we\n> simply send the pack. What is this 3%? Commit list? Initial commit?\n\nIts the recent changes.  If the cached pack starts from the tip of\nmaster, its probably 0%.  But if the repository owner pushes new\nchanges since the cached pack was created, these are sent as a thin\npack in front of the cached pack... and make up that ~3% guess.  For\nlinux-2.6 I tested a 2 week period when the merge window as open right\nafter a release, and the new delta was about 3% of the overall\nrepository size.\n\n> Narrow/Subtree clone is still just an idea, but can pack cache support\n> be made to resumable initial narrow clone too?\n\nThis would be very hard to do.  We could do cached packs for a popular\nset of path specifications (e.g. Documentation/ if documentation only\nediting is common), but once we start getting random requests for path\nspecifications that we cannot predict in advance and pre-pack we'd\nhave to fall back to the normal enumerate code path.\n\n-- \nShawn.\n"},{"id":"160197","messageId":"vpq62t3ejje.fsf@bauges.imag.fr","threadId":"26360","inReplyTo":"20110129231310.GA11088@burratino","subject":"Re: Features from GitSurvey 2010","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-02-01T17:44:53Z","receivedAt":"2011-02-01T17:44:53Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n>> support for tracking empty directories\n>\n> Tricky to get the UI right.  I am interested in and would be glad to\n> help with this one.\n\nA starting point, with some proposed (broken) patches:\n\nhttp://thread.gmane.org/gmane.comp.version-control.git/56310/focus=56348\n\n>> advisory locking / \"this file is being edited\"\n>\n> Probably better to implement out of band (using hooks?).  I don't\n> know of any work or documentation in that direction.\n\nFile locking and distributed tool are conflicting interests. A\nfile-locking tool for git should be able to use a centralized locks\ndatabase (for example, one can imagine a simple PHP script hosted\nsomewhere independantly of the Git repo, keeping a list of locked\nfiles up to date).\n\nThat needs to be integrated with Git, but it should probably still\nremain out of the Git core, because different users would want\ndifferent locking databases. Hooks and git-* commands in the $PATH are\nprobably sufficient.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"160198","messageId":"AANLkTi=u6=mhOd9LFYRy48y41xRcXmYDtktOKoBjjMgO@mail.gmail.com","threadId":"26360","inReplyTo":"20110201172835.GA3771@burratino","subject":"Re: Tracking empty directories","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-01T17:54:35Z","receivedAt":"2011-02-01T17:54:35Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Feb 2, 2011 at 12:28 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n> Jakub Narebski wrote:\n>\n>> Also one needs to remember that this would require adding extension\n>> to git index, because currently it tracks only files, and not\n>> directories.  Explicitly tracking directories in the index could be\n>> useful for other purposes...\n>>\n>> The major difficulty of this is IMHO not the UI, but tracking all those\n>> tricky corner cases (like directory/file conflict, etc.).\n>\n> I have ideas about how to resolve those tricky corner cases, but not\n> about what the UI should look like.  How does one go about adding a\n> directory?  Does it ever get implicitly removed?\n\nI suppose a special command for it is appropriate (git-keepdir?). Many\nindex-related commands are recursive by default and hard to change.\n\nYes I think it should be automatically removed from index when a file\nis added inside tracked directories. Removing those files will also\nremove the containing directory though.\n\n> Would this actually require an index extension, strictly speaking?\n\nCould it be done with an index extension? Interesting.\n\n> Certainly one ought to register an extension name or bump the version\n> number to avoid confusing gits that don't know about the feature.\n\nIndex extension with lowercase name are \"necessary for correct\noperation\". Older git will abort on unknown required extensions. If\nyou add to the main part of the index, better bump version number.\n\n> But after that, couldn't we (e.g.) allow the directory name (ending\n> with '/') as index entry?\n\nYou could. You also need to strip '/' sometimes because certain part\nof git does not expect '/' to be there (traverse_trees or\nunpack_trees, I don't remember).\n-- \nDuy\n"},{"id":"160200","messageId":"20110201181509.GA2370@LK-Perkele-VI.localdomain","threadId":"26360","inReplyTo":"AANLkTi=u6=mhOd9LFYRy48y41xRcXmYDtktOKoBjjMgO@mail.gmail.com","subject":"Re: Tracking empty directories","fromName":"Ilari Liusvaara","fromEmail":"ilari.liusvaara@elisanet.fi","sentAt":"2011-02-01T18:15:09Z","receivedAt":"2011-02-01T18:15:09Z","isPatch":false,"sender":{"key":"ilari.liusvaara@elisanet.fi","avatar":null},"body":"On Wed, Feb 02, 2011 at 12:54:35AM +0700, Nguyen Thai Ngoc Duy wrote:\n> On Wed, Feb 2, 2011 at 12:28 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n> \n> Could it be done with an index extension? Interesting.\n> \n> > Certainly one ought to register an extension name or bump the version\n> > number to avoid confusing gits that don't know about the feature.\n> \n> Index extension with lowercase name are \"necessary for correct\n> operation\". Older git will abort on unknown required extensions. If\n> you add to the main part of the index, better bump version number.\n\nWorse problem than the index: Tree entries. Those are actually transferable\nand IIRC older (current?) git versions don't handle empty subdirectories\n(pointing entry of type directory to empty tree hash) all too well...\n\nWorse yet, there isn't easy way to break the tree parser to avoid current\ngit versions from screwing things up (IIRC, when I tested, invalid octal\nnumbers finally broke it, invalid file types didn't do the trick)...\n\n-Ilari\n"},{"id":"160202","messageId":"201102011931.40559.jnareb@gmail.com","threadId":"26360","inReplyTo":"20110201181509.GA2370@LK-Perkele-VI.localdomain","subject":"Re: Tracking empty directories","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-02-01T18:31:38Z","receivedAt":"2011-02-01T18:31:38Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia wtorek 1. lutego 2011 19:15, Ilari Liusvaara napisał:\n> On Wed, Feb 02, 2011 at 12:54:35AM +0700, Nguyen Thai Ngoc Duy wrote:\n> > On Wed, Feb 2, 2011 at 12:28 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n> > \n> > Could it be done with an index extension? Interesting.\n> > \n> > > Certainly one ought to register an extension name or bump the version\n> > > number to avoid confusing gits that don't know about the feature.\n> > \n> > Index extension with lowercase name are \"necessary for correct\n> > operation\". Older git will abort on unknown required extensions. If\n> > you add to the main part of the index, better bump version number.\n> \n> Worse problem than the index: Tree entries. Those are actually transferable\n> and IIRC older (current?) git versions don't handle empty subdirectories\n> (pointing entry of type directory to empty tree hash) all too well...\n\nWhat did you mean by \"don't handle\" here?  The following entry\n\n  040000 tree 22d5826c087c4b9dcc72e2131c2cfb061403f7eb\tempty\n\nshould be not a problem; empty tree is hardcoded and also shouldn't there\nbe a problem with such object.  Is the problem when checking out such tree\n(writing to index and/or working area)?\n\n> Worse yet, there isn't easy way to break the tree parser to avoid current\n> git versions from screwing things up (IIRC, when I tested, invalid octal\n> numbers finally broke it, invalid file types didn't do the trick)...\n\nWell, then 1.8.0 version could be good place to break backwards \ncompatibility; we did similar thing when introducing submodule entries,\nisn't it?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"160204","messageId":"20110201183508.GE3771@burratino","threadId":"26360","inReplyTo":"AANLkTi=u6=mhOd9LFYRy48y41xRcXmYDtktOKoBjjMgO@mail.gmail.com","subject":"Re: Tracking empty directories","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-01T18:35:08Z","receivedAt":"2011-02-01T18:35:08Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Nguyen Thai Ngoc Duy wrote:\n> On Wed, Feb 2, 2011 at 12:28 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n\n>> I have ideas about how to resolve those tricky corner cases, but not\n>> about what the UI should look like.  How does one go about adding a\n>> directory?  Does it ever get implicitly removed?\n>\n> I suppose a special command for it is appropriate (git-keepdir?). Many\n> index-related commands are recursive by default and hard to change.\n>\n> Yes I think it should be automatically removed from index when a file\n> is added inside tracked directories. Removing those files will also\n> remove the containing directory though.\n\nOkay, I'm convinced.  This fits a \"worse is better\" point of view\nnicely.\n\nTo add, one would use \"git update-index --add\".  The magic disappears\nwhen you register a file within that directory; to tell git you want\nto keep it, one would mkdir and \"git update-index --add\" again.  Once\nit's working, we can think about if there is a need for making that\nlast step automatic after all (my guess: \"no\"). ;-)\n\nUse case: [1]\nNice starting point: [2]\nMotivational word of wisdom: [3]\n\nThis treatment leaves out the backward compatibility detail.  I still\nthink that's the easy part (at worst, we can always implement read\nsupport, wait a year, and then turn on write support).\n\nJonathan\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/46947/focus=47278\n[2] http://thread.gmane.org/gmane.comp.version-control.git/52813/focus=52908\n[3] http://thread.gmane.org/gmane.comp.version-control.git/53494\n"},{"id":"160206","messageId":"20110201184213.GF3771@burratino","threadId":"26360","inReplyTo":"vpq62t3ejje.fsf@bauges.imag.fr","subject":"Re: Features from GitSurvey 2010","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-01T18:42:13Z","receivedAt":"2011-02-01T18:42:13Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Matthieu Moy wrote:\n\n>>> support for tracking empty directories\n[...]\n> http://thread.gmane.org/gmane.comp.version-control.git/56310/focus=56348\n\nThanks!  I followed up a bit on this lead in the \"tracking empty\ndirectories\" thread.\n\n>>> advisory locking / \"this file is being edited\"\n[...]\n> That needs to be integrated with Git, but it should probably still\n> remain out of the Git core, because different users would want\n> different locking databases. Hooks and git-* commands in the $PATH are\n> probably sufficient.\n\nYes, a nice side effect could be the addition of a couple of hooks.\n\nAn rcs-style workflow (lockable files absent from worktree until\nlocked) on top of git sounds fun.\n"},{"id":"160208","messageId":"201102012003.50941.jnareb@gmail.com","threadId":"26360","inReplyTo":"20110201183508.GE3771@burratino","subject":"Re: Tracking empty directories","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-02-01T19:03:46Z","receivedAt":"2011-02-01T19:03:46Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia wtorek 1. lutego 2011 19:35, Jonathan Nieder napisał:\n> Nguyen Thai Ngoc Duy wrote:\n>> On Wed, Feb 2, 2011 at 12:28 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:\n> \n>>> I have ideas about how to resolve those tricky corner cases, but not\n>>> about what the UI should look like.  How does one go about adding a\n>>> directory?  Does it ever get implicitly removed?\n>>\n>> I suppose a special command for it is appropriate (git-keepdir?). Many\n>> index-related commands are recursive by default and hard to change.\n>>\n>> Yes I think it should be automatically removed from index when a file\n>> is added inside tracked directories. Removing those files will also\n>> remove the containing directory though.\n> \n> Okay, I'm convinced.  This fits a \"worse is better\" point of view\n> nicely.\n> \n> To add, one would use \"git update-index --add\".\n\nPorcelain version could be \"git add -N <directory>\", don't you agree?\n\n> The magic disappears when you register a file within that directory;\n> to tell git you want to keep it, one would mkdir and\n> \"git update-index --add\" again.  Once it's working, we can think about\n> if there is a need for making that last step automatic after all\n> (my guess: \"no\"). ;-) \n\nHmmm... could we use mechanism similar to assume-unchanged to mark\ndirectory as explicitely tracked, and that git should not remove it\nwhen it becomes empty?\n\n-- \nJakub Narebski\nPoland\n"},{"id":"160209","messageId":"20110201190915.GB2370@LK-Perkele-VI.localdomain","threadId":"26360","inReplyTo":"201102011931.40559.jnareb@gmail.com","subject":"Re: Tracking empty directories","fromName":"Ilari Liusvaara","fromEmail":"ilari.liusvaara@elisanet.fi","sentAt":"2011-02-01T19:09:15Z","receivedAt":"2011-02-01T19:09:15Z","isPatch":false,"sender":{"key":"ilari.liusvaara@elisanet.fi","avatar":null},"body":"On Tue, Feb 01, 2011 at 07:31:38PM +0100, Jakub Narebski wrote:\n> Dnia wtorek 1. lutego 2011 19:15, Ilari Liusvaara napisał:\n> > \n> > Worse problem than the index: Tree entries. Those are actually transferable\n> > and IIRC older (current?) git versions don't handle empty subdirectories\n> > (pointing entry of type directory to empty tree hash) all too well...\n> \n> What did you mean by \"don't handle\" here?  The following entry\n> \n>   040000 tree 22d5826c087c4b9dcc72e2131c2cfb061403f7eb\tempty\n> \n> should be not a problem; empty tree is hardcoded and also shouldn't there\n> be a problem with such object.  Is the problem when checking out such tree\n> (writing to index and/or working area)?\n\nYes, writing to index/working area. IIRC, having such entry in tree causes\na \"ghost directory\". I don't exactly recall what such thing broke, but I\nremember that it broke something (merging?)...\n\nThose ghosts also had annoying tendency to persist between commits. Commits\ndidn't kill them. Rm didn't work. You had to create something on top/inside to\nget rid of them.\n\n> > Worse yet, there isn't easy way to break the tree parser to avoid current\n> > git versions from screwing things up (IIRC, when I tested, invalid octal\n> > numbers finally broke it, invalid file types didn't do the trick)...\n> \n> Well, then 1.8.0 version could be good place to break backwards \n> compatibility; we did similar thing when introducing submodule entries,\n> isn't it?\n\nHint: Entry of mode \"88888\" blows up the tree parser nicely... :-)\n\nAt the same time, it could be useful to have manually tracked directories\n(incidate via \"sticky\" bit of tree entry mode?)\n\n-Ilari\n"},{"id":"160214","messageId":"vpqzkqfbj2r.fsf@bauges.imag.fr","threadId":"26360","inReplyTo":"20110201184213.GF3771@burratino","subject":"Re: Features from GitSurvey 2010","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2011-02-01T20:23:08Z","receivedAt":"2011-02-01T20:23:08Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> An rcs-style workflow (lockable files absent from worktree until\n> locked) on top of git sounds fun.\n\nThey need not be absent, they can just be read-only (and lock would do\na chmod u+w on the file).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"160220","messageId":"7vy65zzbr4.fsf@alter.siamese.dyndns.org","threadId":"26360","inReplyTo":"AANLkTi=oTL2_ObcyKRb7bf7ZMPZoa1BU7uNH5pJRQtVC@mail.gmail.com","subject":"Re: Features from GitSurvey 2010","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-02-01T21:27:27Z","receivedAt":"2011-02-01T21:27:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:\n\n> On Tue, Feb 1, 2011 at 11:27 PM, Shawn Pearce <spearce@spearce.org> wrote:\n> ...\n>> I think Junio has already started thinking about this one.\n>\n> I need to get nd/pathspec right and implement negative pathspecs\n> before returning to this feature.\n\nI don't think we need negative pathspecs before going forward.\n\nI wanted a unified \"We have a path; is it inside this set of pathspecs?\"\n(and its sibling, \"We have a leading path and a name_entry taken from that\ntree; is it inside this set of pathspecs?\"), and with that we can run:\n\n\t$ git clone git://k.org/pub/scm/git/git.git -- Documentation '*.sh'\n\nthat would limit the clone (not just checkout) to the given parts of the\ntree.  By recording the pathspecs in the repository (and initially making\nit frozen---we can design extending the scope in later rounds), we can\nlimit \"fsck\", \"unpack-trees\", \"log\", etc. all using the unified pathspec\nAPI.\n\nWe may later want to add negative or imaginary pathspecs to the mix, but\nas long as the unified pathspec API understands that, the narrow-clone\npart should be able to be unaware of that.\n\nSo I think that is (or at least _should be_ if the pathspec API is done\nright) pretty much orthogonal.\n"},{"id":"160224","messageId":"alpine.LFD.2.00.1102011542190.8580@xanadu.home","threadId":"26360","inReplyTo":"201102011451.17456.jnareb@gmail.com","subject":"Re: Features from GitSurvey 2010","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-02-01T21:36:53Z","receivedAt":"2011-02-01T21:36:53Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 1 Feb 2011, Jakub Narebski wrote:\n> On Sun, 30 Jan 2011, Jonathan Nieder wrote:\n> > Dmitry S. Kravtsov wrote:\n> > \n> > > resumable clone/fetch (and other remote operations)\n> > \n> > Jakub Narebski seems to be interested in this and Nicolas Pitre has\n> > given some good advice about it.  You can get something usable today\n> > by putting up a git bundle for download over HTTP or rsync, so it is\n> > possible that this just involves some UI (porcelain) and documentation\n> > work to become standard practice.\n> \n> I wouldn't say that: it is Nicolas Pitre (IIRC) who was doing the work;\n> I was only interested party posting comments, but no code.\n\nNo, I'm not working on that.  I provided suggestions on how to go about \nit in the past:\n\n1) The git-archive based solution:\n   http://article.gmane.org/gmane.comp.version-control.git/126431\n   Relatively simple to implement, with questionable efficiency if you \n   care about the full history, but perfectly suited for shallow clones \n   which is what people with flaky connections should aim for anyway.\n\n2) The bundle based solution:\n   http://article.gmane.org/gmane.comp.version-control.git/164699\n   (see towards the end of the message)\n   This was about BitTorrent distribution, but any resumable transport \n   can be applied to the bundle.\n   Extremely simple to implement, as this all can be scripted on top of \n   existing tools.  Good for the bulk of history, but there is always a \n   risk for problems during the update of the repository from the \n   bundle's state up to the most recent commits which has to fall back \n   to the non resumable smart Git protocol.\n\nThere is also some possibility that the cache pack work might be \nleveraged to provide a resumable clone solution similar to #2 above, but \nthat would of course share the same flaws.\n\n> Again, this feature is not very easy to implement, and would require \n> knowledge of git internals including \"smart\" git transport (\"Pro Git\"\n> book can help there).\n\nThe two proposed solutions above require no prior knowledge of the smart \nGit protocol, and they should be pretty simple to implement. Certainly \nin the reach of a GSOC student.\n\n> > > GitTorrent Protocol, or git-mirror\n> > \n> > Sam Vilain and Jonas Fonseca did some good work on this, but it's\n> > stalled.\n> \n> There was some recent discussion on this on git mailing llist, but\n> without any code.\n> \n> One would need to know similar areas as for \"resumable clone\" feature.\n> Plus some knowledge on P2P transport in GitTorrent case.\n\nAgain, please see \n\nhttp://article.gmane.org/gmane.comp.version-control.git/164699\n\nThis is simple, and with guaranteed results.  Why no one was interested \nin implementing that yet I don't know.\n\n\nNicolas\n"},{"id":"160226","messageId":"alpine.LFD.2.00.1102011637560.8580@xanadu.home","threadId":"26360","inReplyTo":"AANLkTi=oTL2_ObcyKRb7bf7ZMPZoa1BU7uNH5pJRQtVC@mail.gmail.com","subject":"Re: Features from GitSurvey 2010","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-02-01T21:44:30Z","receivedAt":"2011-02-01T21:44:30Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 2 Feb 2011, Nguyen Thai Ngoc Duy wrote:\n\n>  - push support for shallow clone (Elijah approach does not base on\n> shallow clone, so it's non-issue)\n\nPush support from a shallow clone should be really simple.  Either you \ncan update the remote, or you can't.  If your local history does include \nthe remote branch head you wish to update then there is nothing \ncurrently that would prevent the push from proceeding as implemented \ntoday.  If the remote head is outside the history subset you have \nlocally then the push simply cannot proceed.\n\n\nNicolas\n"},{"id":"160227","messageId":"alpine.LFD.2.00.1102011647000.8580@xanadu.home","threadId":"26360","inReplyTo":"AANLkTi=KUpYJBRMp9ti0h+g6a0iTw4D113rTgfTpR8C4@mail.gmail.com","subject":"Re: Features from GitSurvey 2010","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-02-01T21:51:08Z","receivedAt":"2011-02-01T21:51:08Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 1 Feb 2011, Shawn Pearce wrote:\n\n> On Tue, Feb 1, 2011 at 09:11, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:\n> > Narrow/Subtree clone is still just an idea, but can pack cache support\n> > be made to resumable initial narrow clone too?\n> \n> This would be very hard to do.  We could do cached packs for a popular\n> set of path specifications (e.g. Documentation/ if documentation only\n> editing is common), but once we start getting random requests for path\n> specifications that we cannot predict in advance and pre-pack we'd\n> have to fall back to the normal enumerate code path.\n\nAlso... people interested in Narrow clones are likely to be shallow \nclone users too, right?\n\n\nNicolas\n"},{"id":"160235","messageId":"alpine.DEB.2.00.1102011443380.10088@asgard.lang.hm","threadId":"26360","inReplyTo":"201102011451.17456.jnareb@gmail.com","subject":"big files in git was: Re: Features from GitSurvey 2010","fromName":"","fromEmail":"david@lang.hm","sentAt":"2011-02-01T22:50:03Z","receivedAt":"2011-02-01T22:50:03Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Tue, 1 Feb 2011, Jakub Narebski wrote:\n\n> On Sun, 30 Jan 2011, Jonathan Nieder wrote:\n>> Hi Dmitry,\n>>\n>> Dmitry S. Kravtsov wrote:\n>>\n>>> I want to dedicate my coursework at University to implementation of\n>>> some useful git feature. So I'm interesting in some kind of list of\n>>> development status of these features\n>> [...]\n>>> Or I'll be glad to know what features are now 'free' and what are\n>>> currently in active development.\n>>\n>> Interesting question.  The short answer is that they are all \"free\".\n>> Generally people seem to be happy to learn of an alternative approach\n>> to what they have been working on.\n>>\n>> [For the following pointers, the easiest way to follow up is probably\n>> to search the mailing list archives.]\n>>\n>>> better support for big files (large media)\n>>\n>> For a conservative approach, you might want to get in touch with Sam\n>> Hocevar, Nicolas Pitre, and Miklos Vajna.  The idea is to stream big\n>> files directly to pack and not waste time trying to compress them.\n>\n> There is also, supposedly stalled, git-bigfiles project.\n\nwhy is the clean/smudge approach that came through the list a week or two \nago not acceptable?\n\nWhile people talked about how it would be nice to store the large files on \n$remote_destination, just create a .git/bigfiles and store them in there.\n\nwith the ability to pass the filename to the clean/smudge scripts, you can \neven avoid the copy (replacing it with a mv) and have a working, if \nbare-bones system.\n\nThen people can create/submit enhanced versions of these scripts that \nstore the large files elsewhere if they want, but we would be past the \n\"git can't handle large files\" into \"git handles large files less \nefficiently\", which is a much better place to be.\n\nIf nobody else has time to take those e-mails and create a set of \nclean/smudge scripts, I'll do so later this week (unless there is some \nreason why they wouldn't be acceptable)\n\nI guess the only question is how to tell what files need to be handled \nthis way, but can't we have something in .gitattributes about the file \nsize? (and if that's a problem for checking files out, have the stored \nfile be a sparse file, that way it's large, but doesn't take much space on \nsane filesystems)\n\nDavid Lang\n"},{"id":"160243","messageId":"AANLkTikaztSn+xQ3xT7d-3-Yghk69qXXN1DRg9h+kEHx@mail.gmail.com","threadId":"26360","inReplyTo":"alpine.LFD.2.00.1102011647000.8580@xanadu.home","subject":"Re: Features from GitSurvey 2010","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2011-02-02T00:26:16Z","receivedAt":"2011-02-02T00:26:16Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"On Tue, Feb 1, 2011 at 13:51, Nicolas Pitre <nico@fluxnic.net> wrote:\n> On Tue, 1 Feb 2011, Shawn Pearce wrote:\n>\n>> On Tue, Feb 1, 2011 at 09:11, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:\n>> > Narrow/Subtree clone is still just an idea, but can pack cache support\n>> > be made to resumable initial narrow clone too?\n>>\n>> This would be very hard to do.  We could do cached packs for a popular\n>> set of path specifications (e.g. Documentation/ if documentation only\n>> editing is common), but once we start getting random requests for path\n>> specifications that we cannot predict in advance and pre-pack we'd\n>> have to fall back to the normal enumerate code path.\n>\n> Also... people interested in Narrow clones are likely to be shallow\n> clone users too, right?\n\nI think that depends.  Some users might want the full history of the\nfiles they are working on.  Others wouldn't care and just want the tip\nrevision so they can make changes.  Obviously a shallow clone of depth\n1 is very cheap to implement on the server; there really isn't any\ncaching required.\n\nProbably 50% want full history, 50% want shallow clone.  So I doubt we\ncan assume that narrow implies shallow and thus is cheap.  :-(\n\n-- \nShawn.\n"},{"id":"160245","messageId":"alpine.LFD.2.00.1102012110320.8580@xanadu.home","threadId":"26360","inReplyTo":"AANLkTikaztSn+xQ3xT7d-3-Yghk69qXXN1DRg9h+kEHx@mail.gmail.com","subject":"Re: Features from GitSurvey 2010","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-02-02T02:11:37Z","receivedAt":"2011-02-02T02:11:37Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 1 Feb 2011, Shawn Pearce wrote:\n\n> On Tue, Feb 1, 2011 at 13:51, Nicolas Pitre <nico@fluxnic.net> wrote:\n> > On Tue, 1 Feb 2011, Shawn Pearce wrote:\n> >\n> >> On Tue, Feb 1, 2011 at 09:11, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:\n> >> > Narrow/Subtree clone is still just an idea, but can pack cache support\n> >> > be made to resumable initial narrow clone too?\n> >>\n> >> This would be very hard to do.  We could do cached packs for a popular\n> >> set of path specifications (e.g. Documentation/ if documentation only\n> >> editing is common), but once we start getting random requests for path\n> >> specifications that we cannot predict in advance and pre-pack we'd\n> >> have to fall back to the normal enumerate code path.\n> >\n> > Also... people interested in Narrow clones are likely to be shallow\n> > clone users too, right?\n> \n> I think that depends.  Some users might want the full history of the\n> files they are working on.  Others wouldn't care and just want the tip\n> revision so they can make changes.  Obviously a shallow clone of depth\n> 1 is very cheap to implement on the server; there really isn't any\n> caching required.\n> \n> Probably 50% want full history, 50% want shallow clone.  So I doubt we\n> can assume that narrow implies shallow and thus is cheap.  :-(\n\nLet's see what happens when this gets used in the wild.\n\n\nNicolas\n"},{"id":"160247","messageId":"alpine.DEB.2.00.1102011822340.10088@asgard.lang.hm","threadId":"26360","inReplyTo":"alpine.LFD.2.00.1102012110320.8580@xanadu.home","subject":"Re: Features from GitSurvey 2010","fromName":"","fromEmail":"david@lang.hm","sentAt":"2011-02-02T02:23:48Z","receivedAt":"2011-02-02T02:23:48Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Tue, 1 Feb 2011, Nicolas Pitre wrote:\n\n> On Tue, 1 Feb 2011, Shawn Pearce wrote:\n>\n>> On Tue, Feb 1, 2011 at 13:51, Nicolas Pitre <nico@fluxnic.net> wrote:\n>>> On Tue, 1 Feb 2011, Shawn Pearce wrote:\n>>>\n>>>> On Tue, Feb 1, 2011 at 09:11, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:\n>>>>> Narrow/Subtree clone is still just an idea, but can pack cache support\n>>>>> be made to resumable initial narrow clone too?\n>>>>\n>>>> This would be very hard to do.  We could do cached packs for a popular\n>>>> set of path specifications (e.g. Documentation/ if documentation only\n>>>> editing is common), but once we start getting random requests for path\n>>>> specifications that we cannot predict in advance and pre-pack we'd\n>>>> have to fall back to the normal enumerate code path.\n>>>\n>>> Also... people interested in Narrow clones are likely to be shallow\n>>> clone users too, right?\n>>\n>> I think that depends.  Some users might want the full history of the\n>> files they are working on.  Others wouldn't care and just want the tip\n>> revision so they can make changes.  Obviously a shallow clone of depth\n>> 1 is very cheap to implement on the server; there really isn't any\n>> caching required.\n>>\n>> Probably 50% want full history, 50% want shallow clone.  So I doubt we\n>> can assume that narrow implies shallow and thus is cheap.  :-(\n>\n> Let's see what happens when this gets used in the wild.\n\nalso, many users may assume that a full clone is very expensive, but for \ncode-based projects a full clone is usually comparable to the size to \ndownload a single tarball.\n\nif you have large binary files this changes, but most projects don't.\n\nDavid Lang"},{"id":"160253","messageId":"AANLkTikkymYmnXh7XB1SM8br_oK-YmAJYfkwjTuLzr+f@mail.gmail.com","threadId":"26360","inReplyTo":"201102012003.50941.jnareb@gmail.com","subject":"Re: Tracking empty directories","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2011-02-02T03:54:49Z","receivedAt":"2011-02-02T03:54:49Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Wed, Feb 2, 2011 at 2:03 AM, Jakub Narebski <jnareb@gmail.com> wrote:\n>> To add, one would use \"git update-index --add\".\n>\n> Porcelain version could be \"git add -N <directory>\", don't you agree?\n\n\"git add\" is recursive, with or without -N. What I worry is user\naccidentally \"git add -N <dir>\" where <dir> is not empty, which adds\neverything in <dir>.\n\n>> The magic disappears when you register a file within that directory;\n>> to tell git you want to keep it, one would mkdir and\n>> \"git update-index --add\" again.  Once it's working, we can think about\n>> if there is a need for making that last step automatic after all\n>> (my guess: \"no\"). ;-)\n>\n> Hmmm... could we use mechanism similar to assume-unchanged to mark\n> directory as explicitely tracked, and that git should not remove it\n> when it becomes empty?\n\nI think git-attr suits better, more persistent. Although if you insist\nthe directory must stay, why not just put a hidden file in there?\n-- \nDuy\n"},{"id":"160269","messageId":"4D494EAA.2060803@digium.com","threadId":"26360","inReplyTo":"AANLkTikkymYmnXh7XB1SM8br_oK-YmAJYfkwjTuLzr+f@mail.gmail.com","subject":"Re: Tracking empty directories","fromName":"Kevin P. Fleming","fromEmail":"kpfleming@digium.com","sentAt":"2011-02-02T12:31:38Z","receivedAt":"2011-02-02T12:31:38Z","isPatch":false,"sender":{"key":"kpfleming@digium.com","avatar":null},"body":"On 02/01/2011 09:54 PM, Nguyen Thai Ngoc Duy wrote:\n> On Wed, Feb 2, 2011 at 2:03 AM, Jakub Narebski<jnareb@gmail.com>  wrote:\n>>> To add, one would use \"git update-index --add\".\n>>\n>> Porcelain version could be \"git add -N<directory>\", don't you agree?\n>\n> \"git add\" is recursive, with or without -N. What I worry is user\n> accidentally \"git add -N<dir>\" where<dir>  is not empty, which adds\n> everything in<dir>.\n>\n>>> The magic disappears when you register a file within that directory;\n>>> to tell git you want to keep it, one would mkdir and\n>>> \"git update-index --add\" again.  Once it's working, we can think about\n>>> if there is a need for making that last step automatic after all\n>>> (my guess: \"no\"). ;-)\n>>\n>> Hmmm... could we use mechanism similar to assume-unchanged to mark\n>> directory as explicitely tracked, and that git should not remove it\n>> when it becomes empty?\n>\n> I think git-attr suits better, more persistent. Although if you insist\n> the directory must stay, why not just put a hidden file in there?\n\nThat's what I do now... in fact, since the empty directory needs to \nexist in checkouts *and* be empty, adding a .gitignore file with content \n'*' works quite well.\n\n-- \nKevin P. Fleming\nDigium, Inc. | Director of Software Technologies\n445 Jan Davis Drive NW - Huntsville, AL 35806 - USA\nskype: kpfleming | jabber: kfleming@digium.com\nCheck us out at www.digium.com & www.asterisk.org\n"},{"id":"160317","messageId":"alpine.LFD.2.00.1102030118090.12104@xanadu.home","threadId":"26360","inReplyTo":"alpine.DEB.2.00.1102011443380.10088@asgard.lang.hm","subject":"Re: big files in git was: Re: Features from GitSurvey 2010","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-02-03T06:25:56Z","receivedAt":"2011-02-03T06:25:56Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 1 Feb 2011, david@lang.hm wrote:\n\n> On Tue, 1 Feb 2011, Jakub Narebski wrote:\n> \n> > There is also, supposedly stalled, git-bigfiles project.\n> \n> why is the clean/smudge approach that came through the list a week or two ago\n> not acceptable?\n\nNo idea.\n\nI suppose that's because it is not complicated enough to actually be \ninteresting.  This is like my suggestion for simply distributing bundles \nwith BitTorrent.\n\n> If nobody else has time to take those e-mails and create a set of clean/smudge\n> scripts, I'll do so later this week (unless there is some reason why they\n> wouldn't be acceptable)\n\nPlease do so.  The contrib directory would be a pretty good place to put \nthem.\n\n> I guess the only question is how to tell what files need to be handled this\n> way, but can't we have something in .gitattributes about the file size?\n\nSurely.  There is even a core.bigFileThreshold config variable already \nwhich could be reused right away for this purpose.\n\n\nNicolas\n"},{"id":"160328","messageId":"FE2BDD68-9CFA-4CBB-9F66-32BE6CF3E174@adacore.com","threadId":"26360","inReplyTo":"alpine.LFD.2.00.1102011647000.8580@xanadu.home","subject":"Re: Features from GitSurvey 2010","fromName":"Geert Bosch","fromEmail":"bosch@adacore.com","sentAt":"2011-02-03T14:38:27Z","receivedAt":"2011-02-03T14:38:27Z","isPatch":false,"sender":{"key":"bosch@adacore.com","avatar":null},"body":"\nOn Feb 1, 2011, at 16:51, Nicolas Pitre wrote:\n\n> Also... people interested in Narrow clones are likely to be shallow \n> clone users too, right?\n\nNot necessarily. Many corporate repositories are huge (caused by\nthe concept of 1 central repository with everything in it) and have\ntons of crud (like marketing materials, media-heavy powerpoint\npresentations).  Here you really want a narrow clone (such as the\nsources of the project you're working on), but don't mind having\nthe whole history.\n\nLooking at it from another angle: typically the whole history of a\nproject is not much bigger than a check out, so it is fine to have\na deep history. On the other hand, for these monster repositories\none would typically do a narrow clone of only a single subdirectory\nthat may be more than an order of magnitude smaller.\n\nThese narrow clones are especially important for imports of unwieldy\nsvn repositories where there is a large amount of unstructured\nbranching.\n\nRegards,\n   -Geert\n"},{"id":"160339","messageId":"20110203173835.GC30341@elie","threadId":"26360","inReplyTo":"FE2BDD68-9CFA-4CBB-9F66-32BE6CF3E174@adacore.com","subject":"Narrow clone (Re: features from GitSurvey 2010)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-03T17:39:09Z","receivedAt":"2011-02-03T17:39:09Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Geert Bosch wrote:\n\n> These narrow clones are especially important for imports of unwieldy\n> svn repositories where there is a large amount of unstructured\n> branching.\n\nWouldn't a more careful import be a better solution to that problem?\nPractically speaking, I'd rather work with an enormous svn repo like\nthat by using git-svn to extract subsets than with a botched import\nthat treats it as one huge (git-managed) project.\n\nsvn-all-fast-import, for example, has a fairly simple configuration\nsyntax allowing to extract whatever subrepositories are needed.\n"},{"id":"160353","messageId":"5E0364BF-35CD-4797-BBAF-98A54D1F7F6E@adacore.com","threadId":"26360","inReplyTo":"20110203173835.GC30341@elie","subject":"Re: Narrow clone (Re: features from GitSurvey 2010)","fromName":"Geert Bosch","fromEmail":"bosch@adacore.com","sentAt":"2011-02-03T21:23:57Z","receivedAt":"2011-02-03T21:23:57Z","isPatch":false,"sender":{"key":"bosch@adacore.com","avatar":null},"body":"\nOn Feb 3, 2011, at 12:39, Jonathan Nieder wrote:\n\n> Geert Bosch wrote:\n> \n>> These narrow clones are especially important for imports of unwieldy\n>> svn repositories where there is a large amount of unstructured\n>> branching.\n> \n> Wouldn't a more careful import be a better solution to that problem?\n\nYes.\n\n> Practically speaking, I'd rather work with an enormous svn repo like\n> that by using git-svn to extract subsets than with a botched import\n> that treats it as one huge (git-managed) project.\n\nPractically speaking, I don't always have a say in the organization\nof repositories that I have to work with. Some would rather\nspend 30+ days of CPU time to import an entire SVN repository with\nbranch forests straight into git than considering organization.\nOf course the resulting git repository will be less than useful.\nAnd that's where the narrow clone comes in handy...\n\n  -Geert\n"},{"id":"160354","messageId":"20110203213315.GD16391@elie","threadId":"26360","inReplyTo":"5E0364BF-35CD-4797-BBAF-98A54D1F7F6E@adacore.com","subject":"Re: Narrow clone (Re: features from GitSurvey 2010)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-03T21:33:15Z","receivedAt":"2011-02-03T21:33:15Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Geert Bosch wrote:\n\n>                                           Some would rather\n> spend 30+ days of CPU time to import an entire SVN repository with\n> branch forests straight into git than considering organization.\n> Of course the resulting git repository will be less than useful.\n> And that's where the narrow clone comes in handy...\n\nRight, narrow clone gives them an excuse to do it.  Ergo we should\nnot have narrow clone. ;-)\n"},{"id":"160355","messageId":"alpine.LFD.2.00.1102031630520.12104@xanadu.home","threadId":"26360","inReplyTo":"FE2BDD68-9CFA-4CBB-9F66-32BE6CF3E174@adacore.com","subject":"Re: Features from GitSurvey 2010","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2011-02-03T21:33:31Z","receivedAt":"2011-02-03T21:33:31Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 3 Feb 2011, Geert Bosch wrote:\n\n> \n> On Feb 1, 2011, at 16:51, Nicolas Pitre wrote:\n> \n> > Also... people interested in Narrow clones are likely to be shallow \n> > clone users too, right?\n> \n> Not necessarily. Many corporate repositories are huge (caused by\n> the concept of 1 central repository with everything in it) and have\n> tons of crud (like marketing materials, media-heavy powerpoint\n> presentations).  Here you really want a narrow clone (such as the\n> sources of the project you're working on), but don't mind having\n> the whole history.\n\nOK.  I was asking just to see if the cache pack concept might have to \ncater for that case too.  but let's wait for proper narrow clone support \nfirst.\n\n\nNicolas\n"},{"id":"160356","messageId":"20110203213830.GE16391@elie","threadId":"26360","inReplyTo":"5E0364BF-35CD-4797-BBAF-98A54D1F7F6E@adacore.com","subject":"Re: Narrow clone (Re: features from GitSurvey 2010)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-02-03T21:38:30Z","receivedAt":"2011-02-03T21:38:30Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Geert Bosch wrote:\n\n> Of course the resulting git repository will be less than useful.\n> And that's where the narrow clone comes in handy...\n\nSide note: while clearly I don't consider this particular use case to\nbe a strong motivation, there are other use cases that do strongly\nmotivate the feature.  And if this particular use case happens to\nmotivate someone to work on it, I'd be happy for it still.  I just\nhope the documentation does not encourage people to do such things.\n"}]}