{"thread":{"id":"8139","subject":"What's cooking in git.git (topics)","startedAt":"2007-05-13T22:29:49Z","lastAt":"2007-07-28T08:47:20Z","messageCount":34,"participants":["Junio C Hamano","Julian Phillips","Daniel Barkalow","Shawn O. Pearce","Johannes Schindelin","Nicolas Pitre","Dana How","Linus Torvalds","Matthias Lederhofer","Jeffrey C. Ollie"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"42061","messageId":"7v646wqrvm.fsf@assigned-by-dhcp.cox.net","threadId":"8139","inReplyTo":null,"subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-13T22:29:49Z","receivedAt":"2007-05-13T22:29:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking.  Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'.  The topics list the commits in reverse chronological\norder.\n\n* sp/cvsexport (Thu May 10 01:06:36 2007 +0200) 1 commit\n - Optimized cvsexportcommit: calling 'cvs status' once instead of\n   once per touched file.\n\nThis is waiting for Ack/Nack to make sure there is no unexpected\nside effects but I am hoping we can ship v1.5.2 with this.\n\n* dh/pack (Wed May 9 13:56:50 2007 -0700) 3 commits\n + Custom compression levels for objects and packs\n + make \"repack -f\" imply \"pack-objects --no-reuse-object\"\n + allow for undeltified objects not to be reused\n* tt/gc (Wed May 9 15:48:39 2007 -0400) 1 commit\n + Add --aggressive option to 'git gc'\n* np/pack (Wed May 9 14:42:42 2007 -0400) 3 commits\n + deprecate the new loose object header format\n + make \"repack -f\" imply \"pack-objects --no-reuse-object\"\n + allow for undeltified objects not to be reused\n* sv/checkout (Wed May 9 12:33:20 2007 +0200) 1 commit\n + git-update-ref: add --no-deref option for overwriting/detaching\n   ref\n* jb/statcolor (Sat May 5 16:48:54 2007 -0400) 1 commit\n + Add colour support in rebase and merge tree diff stats output.\n\nNew features, all deemed to be safe.  To merge early after v1.5.2.\n\n* db/remote (Sat May 12 11:46:03 2007 -0400) 3 commits\n - Add handlers for fetch-side configuration of remotes.\n - Move refspec parser from connect.c and cache.h to remote.{c,h}\n - Move remote parsing into a library file out of builtin-push.\n\nHopefully be in 'next' after v1.5.2; I haven't really played\nwith it.  The next step would probably be to add some stuff that\nuse this series in fetch--tool, to further rewrite git-fetch\nitself in C, or maybe wholesale rewrite of git-fetch in C.\n\n* dh/repack (Tue May 8 13:05:04 2007 -0700) 5 commits\n - git-repack --max-pack-size: add option parsing to enable feature\n - git-repack --max-pack-size: split packs as asked by\n   write_{object,one}()\n - git-repack --max-pack-size: write_{object,one}() respect pack\n   limit\n - git-repack --max-pack-size: new file statics and code\n   restructuring\n - Alter sha1close() 3rd argument to request flush only\n\nHopefully will have a series rebased on top of 'master' after\nthe first batch after v1.5.2 graduates.\n\n* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits\n - blame: show log as it goes\n - git-blame: optimize get_origin() from linear search to hash-\n   lookup.\n - git-blame: pass \"struct scoreboard *\" pointers around.\n - blame: lift structure definitions up\n* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits\n - test-para: combined diff between HEAD, index and working tree.\n - para-walk: walk n trees, index and working tree in parallel\n\nStalled.\n"},{"id":"42063","messageId":"Pine.LNX.4.64.0705132348290.4791@beast.quantumfyre.co.uk","threadId":"8139","inReplyTo":"7v646wqrvm.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-05-13T22:58:11Z","receivedAt":"2007-05-13T22:58:11Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Sun, 13 May 2007, Junio C Hamano wrote:\n\n> * db/remote (Sat May 12 11:46:03 2007 -0400) 3 commits\n> - Add handlers for fetch-side configuration of remotes.\n> - Move refspec parser from connect.c and cache.h to remote.{c,h}\n> - Move remote parsing into a library file out of builtin-push.\n>\n> Hopefully be in 'next' after v1.5.2; I haven't really played\n> with it.  The next step would probably be to add some stuff that\n> use this series in fetch--tool, to further rewrite git-fetch\n> itself in C, or maybe wholesale rewrite of git-fetch in C.\n\nFWIW, I've got a largely functional C version of git-fetch ... the main \nfunctionality is there - but it's not complete yet.  In \naddition to some of the non-core functionality being missing \n(e.g. --tags or --no-tags in tagopt), I haven't been keeping \nup with recent updates to fetch/fetch-tool.  I was hoping to \nhave it ready for post-1.5.2 - unfortunately I've been rather busy the \nlast couple of weeks, and haven't managed to get as far as I'd hoped.\n\n-- \nJulian\n\n  ---\nbyob, v:\n \tBelieving Your Own Bull\n"},{"id":"42069","messageId":"7vzm48pacj.fsf@assigned-by-dhcp.cox.net","threadId":"8139","inReplyTo":"Pine.LNX.4.64.0705132348290.4791@beast.quantumfyre.co.uk","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-13T23:33:48Z","receivedAt":"2007-05-13T23:33:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Julian Phillips <julian@quantumfyre.co.uk> writes:\n\n> On Sun, 13 May 2007, Junio C Hamano wrote:\n>\n>> * db/remote (Sat May 12 11:46:03 2007 -0400) 3 commits\n>> - Add handlers for fetch-side configuration of remotes.\n>> - Move refspec parser from connect.c and cache.h to remote.{c,h}\n>> - Move remote parsing into a library file out of builtin-push.\n>>\n>> Hopefully be in 'next' after v1.5.2; I haven't really played\n>> with it.  The next step would probably be to add some stuff that\n>> use this series in fetch--tool, to further rewrite git-fetch\n>> itself in C, or maybe wholesale rewrite of git-fetch in C.\n>\n> FWIW, I've got a largely functional C version of git-fetch ... the\n> main functionality is there - but it's not complete yet.  In addition\n> to some of the non-core functionality being missing (e.g. --tags or\n> --no-tags in tagopt), I haven't been keeping up with recent updates to\n> fetch/fetch-tool.  I was hoping to have it ready for post-1.5.2 -\n> unfortunately I've been rather busy the last couple of weeks, and\n> haven't managed to get as far as I'd hoped.\n\nThanks for the status updates.  Although I do not recall Daniel\nsaying it explicitly, I have been assuming that his series was\naiming for the same all along.  It might be a good idea for you\ntwo to compare notes sometime between now and v1.5.2?\n"},{"id":"42079","messageId":"Pine.LNX.4.64.0705140121030.5520@beast.quantumfyre.co.uk","threadId":"8139","inReplyTo":"7vzm48pacj.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Julian Phillips","fromEmail":"julian@quantumfyre.co.uk","sentAt":"2007-05-14T00:38:29Z","receivedAt":"2007-05-14T00:38:29Z","isPatch":false,"sender":{"key":"julian@quantumfyre.co.uk","avatar":"https://avatars.githubusercontent.com/u/948888?v=4"},"body":"On Sun, 13 May 2007, Junio C Hamano wrote:\n\n> Julian Phillips <julian@quantumfyre.co.uk> writes:\n>\n>> On Sun, 13 May 2007, Junio C Hamano wrote:\n>>\n>>> * db/remote (Sat May 12 11:46:03 2007 -0400) 3 commits\n>>> - Add handlers for fetch-side configuration of remotes.\n>>> - Move refspec parser from connect.c and cache.h to remote.{c,h}\n>>> - Move remote parsing into a library file out of builtin-push.\n>>>\n>>> Hopefully be in 'next' after v1.5.2; I haven't really played\n>>> with it.  The next step would probably be to add some stuff that\n>>> use this series in fetch--tool, to further rewrite git-fetch\n>>> itself in C, or maybe wholesale rewrite of git-fetch in C.\n>>\n>> FWIW, I've got a largely functional C version of git-fetch ... the\n>> main functionality is there - but it's not complete yet.  In addition\n>> to some of the non-core functionality being missing (e.g. --tags or\n>> --no-tags in tagopt), I haven't been keeping up with recent updates to\n>> fetch/fetch-tool.  I was hoping to have it ready for post-1.5.2 -\n>> unfortunately I've been rather busy the last couple of weeks, and\n>> haven't managed to get as far as I'd hoped.\n>\n> Thanks for the status updates.  Although I do not recall Daniel\n> saying it explicitly, I have been assuming that his series was\n> aiming for the same all along.  It might be a good idea for you\n> two to compare notes sometime between now and v1.5.2?\n\nWell, it can't be a bad idea, can it? ;)\n\nApart from the code itself (which can be found at \nhttp://git.q42.co.uk/w/fetch2.git), I don't have any actual notes, and \nsince I haven't had a chance to work on it for a couple of weeks I'm \nnot 100% sure of where I was at - due to lack of time I have tended to \njust spend a few hours adding some missing part when I found the time but \nI don't actually have a TODO list or similar (though I really should).\n\nI'm also out of town with work for the first half of the coming week ... \nbut I'm certainly willing to talk about what I have and haven't done.\n\n(Daniel, hope you don't mind me adding you to CC ...)\n\n-- \nJulian\n\n  ---\nThe cable TV sex channels don't expand our horizons, don't make us better\npeople, and don't come in clearly enough.\n \t\t-- Bill Maher\n"},{"id":"42093","messageId":"Pine.LNX.4.64.0705132234001.18541@iabervon.org","threadId":"8139","inReplyTo":"Pine.LNX.4.64.0705140121030.5520@beast.quantumfyre.co.uk","subject":"Re: What's cooking in git.git (topics)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-05-14T03:21:05Z","receivedAt":"2007-05-14T03:21:05Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Mon, 14 May 2007, Julian Phillips wrote:\n\n> On Sun, 13 May 2007, Junio C Hamano wrote:\n> \n> > Thanks for the status updates.  Although I do not recall Daniel\n> > saying it explicitly, I have been assuming that his series was\n> > aiming for the same all along.  It might be a good idea for you\n> > two to compare notes sometime between now and v1.5.2?\n> \n> Well, it can't be a bad idea, can it? ;)\n> \n> Apart from the code itself (which can be found at\n> http://git.q42.co.uk/w/fetch2.git), I don't have any actual notes, and since I\n> haven't had a chance to work on it for a couple of weeks I'm not 100% sure of\n> where I was at - due to lack of time I have tended to just spend a few hours\n> adding some missing part when I found the time but I don't actually have a\n> TODO list or similar (though I really should).\n> \n> I'm also out of town with work for the first half of the coming week ... but\n> I'm certainly willing to talk about what I have and haven't done.\n\nI've actually been largely unsuccessful in figuring out how to do most of \nthe fetch logic in C, but I was expecting that somebody would write it if \nthe library were available.\n\nI've been working on various little things that are a lot easier if the \nparsing is centralized:\n\n * update tracking refs on push\n * handle refspec patterns in match_refs so that send-pack/http-push can \n   take them and builtin-push doesn't need to do anything, and can also\n   turn --tags into +refs/tags/*:refs/tags/*.\n\nI've also been looking at doing something like your remote_ops, but also \nincluding something for push, and doing it in another library file (so \npush, fetch, and ls-remote can all share the same dispatch on type of \nurl).\n\n> (Daniel, hope you don't mind me adding you to CC ...)\n\nNot at all; I hadn't noticed this thread yet, and it's quite related to \nwhat I'm working on.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"42347","messageId":"7vfy5wcnbg.fsf@assigned-by-dhcp.cox.net","threadId":"8139","inReplyTo":"7v646wqrvm.fsf@assigned-by-dhcp.cox.net","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-17T00:21:07Z","receivedAt":"2007-05-17T00:21:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"It probably would be more interesting to look at the earlier\n\"What's not in 1.5.2\" messages, but here is the current status\nof my tree on the 'next' and 'pu' front.\n\nHere are the topics that have been cooking.  Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'.  The topics list the commits in reverse chronological\norder.\n\n* mst/connect (Wed May 16 20:09:41 2007 +0300) 1 commit\n + connect: display connection progress\n* db/remote (Tue May 15 22:50:19 2007 -0400) 5 commits\n - Update local tracking refs when pushing\n - Add handlers for fetch-side configuration of remotes.\n - Move refspec parser from connect.c and cache.h to remote.{c,h}\n - Move remote parsing into a library file out of builtin-push.\n + git-update-ref: add --no-deref option for overwriting/detaching\n   ref\n* dh/repack (Sun May 13 12:47:09 2007 -0700) 9 commits\n - git-repack --max-pack-size: add option parsing to enable feature\n - git-repack --max-pack-size: split packs as asked by\n   write_{object,one}()\n - git-repack --max-pack-size: write_{object,one}() respect pack\n   limit\n - git-repack --max-pack-size: new file statics and code\n   restructuring\n - Alter sha1close() 3rd argument to request flush only\n + Custom compression levels for objects and packs\n + deprecate the new loose object header format\n + make \"repack -f\" imply \"pack-objects --no-reuse-object\"\n + allow for undeltified objects not to be reused\n* sp/cvsexport (Thu May 10 01:06:36 2007 +0200) 1 commit\n + Optimized cvsexportcommit: calling 'cvs status' once instead of\n   once per touched file.\n* dh/pack (Wed May 9 13:56:50 2007 -0700) 3 commits\n + Custom compression levels for objects and packs\n + make \"repack -f\" imply \"pack-objects --no-reuse-object\"\n + allow for undeltified objects not to be reused\n* tt/gc (Wed May 9 15:48:39 2007 -0400) 1 commit\n + Add --aggressive option to 'git gc'\n* np/pack (Wed May 9 14:42:42 2007 -0400) 3 commits\n + deprecate the new loose object header format\n + make \"repack -f\" imply \"pack-objects --no-reuse-object\"\n + allow for undeltified objects not to be reused\n* sv/checkout (Wed May 9 12:33:20 2007 +0200) 1 commit\n + git-update-ref: add --no-deref option for overwriting/detaching\n   ref\n* jb/statcolor (Sat May 5 16:48:54 2007 -0400) 1 commit\n + Add colour support in rebase and merge tree diff stats output.\n* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits\n - blame: show log as it goes\n - git-blame: optimize get_origin() from linear search to hash-\n   lookup.\n - git-blame: pass \"struct scoreboard *\" pointers around.\n - blame: lift structure definitions up\n* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits\n - test-para: combined diff between HEAD, index and working tree.\n - para-walk: walk n trees, index and working tree in parallel\n"},{"id":"42356","messageId":"Pine.LNX.4.64.0705162057380.18541@iabervon.org","threadId":"8139","inReplyTo":"7vfy5wcnbg.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-05-17T02:07:04Z","receivedAt":"2007-05-17T02:07:04Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 16 May 2007, Junio C Hamano wrote:\n\n> It probably would be more interesting to look at the earlier\n> \"What's not in 1.5.2\" messages, but here is the current status\n> of my tree on the 'next' and 'pu' front.\n> \n> Here are the topics that have been cooking.  Commits prefixed\n> with '-' are only in 'pu' while commits prefixed with '+' are\n> in 'next'.  The topics list the commits in reverse chronological\n> order.\n> \n> * db/remote (Tue May 15 22:50:19 2007 -0400) 5 commits\n>  - Update local tracking refs when pushing\n>  - Add handlers for fetch-side configuration of remotes.\n>  - Move refspec parser from connect.c and cache.h to remote.{c,h}\n>  - Move remote parsing into a library file out of builtin-push.\n>  + git-update-ref: add --no-deref option for overwriting/detaching\n>    ref\n\nAFAICT, this isn't really in my topic. Rebased too much, perhaps?\n\nI've also got one more patch ready, which moves refspec pattern matching \ninto match_refs, for a net reduction of 50 lines and much simpler logic.\n\nI've also started making Julian Phillips' builtin-fetch use my parser, so \nI might have something ready before too long.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"42370","messageId":"7vzm44axzl.fsf@assigned-by-dhcp.cox.net","threadId":"8139","inReplyTo":"Pine.LNX.4.64.0705162057380.18541@iabervon.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-17T04:13:34Z","receivedAt":"2007-05-17T04:13:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> On Wed, 16 May 2007, Junio C Hamano wrote:\n> ...\n>> * db/remote (Tue May 15 22:50:19 2007 -0400) 5 commits\n>>  - Update local tracking refs when pushing\n>>  - Add handlers for fetch-side configuration of remotes.\n>>  - Move refspec parser from connect.c and cache.h to remote.{c,h}\n>>  - Move remote parsing into a library file out of builtin-push.\n>>  + git-update-ref: add --no-deref option for overwriting/detaching\n>>    ref\n>\n> AFAICT, this isn't really in my topic. Rebased too much, perhaps?\n\nYou have a new call to lock_any_ref_for_update() in the last\npatch in your series, whose function signature is changed by\nSven's \"add --no-deref\".\n\nBecause the latter is already scheduled for 'master' post 1.5.2,\nI rebased the remote series on top of it, to adjust to the\nchange early (i.e. while my memory is still fresh).\n\nThat's what\n\n\tThis was rebased on to Sven's change to lock_any_ref_for_update();\n\ncomment was about in the earlier \"[2/4] What's not in 1.5.2\" message.\n"},{"id":"42372","messageId":"Pine.LNX.4.64.0705170017050.18541@iabervon.org","threadId":"8139","inReplyTo":"7vzm44axzl.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-05-17T04:31:00Z","receivedAt":"2007-05-17T04:31:00Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 16 May 2007, Junio C Hamano wrote:\n\n> Daniel Barkalow <barkalow@iabervon.org> writes:\n> \n> > On Wed, 16 May 2007, Junio C Hamano wrote:\n> > ...\n> >> * db/remote (Tue May 15 22:50:19 2007 -0400) 5 commits\n> >>  - Update local tracking refs when pushing\n> >>  - Add handlers for fetch-side configuration of remotes.\n> >>  - Move refspec parser from connect.c and cache.h to remote.{c,h}\n> >>  - Move remote parsing into a library file out of builtin-push.\n> >>  + git-update-ref: add --no-deref option for overwriting/detaching\n> >>    ref\n> >\n> > AFAICT, this isn't really in my topic. Rebased too much, perhaps?\n> \n> You have a new call to lock_any_ref_for_update() in the last\n> patch in your series, whose function signature is changed by\n> Sven's \"add --no-deref\".\n> \n> Because the latter is already scheduled for 'master' post 1.5.2,\n> I rebased the remote series on top of it, to adjust to the\n> change early (i.e. while my memory is still fresh).\n> \n> That's what\n> \n> \tThis was rebased on to Sven's change to lock_any_ref_for_update();\n> \n> comment was about in the earlier \"[2/4] What's not in 1.5.2\" message.\n\nOh, okay. I noticed the change, but missed that what it was rebased \nonto wasn't simply in the implicit base for the series, and also didn't \nrealize that it was supposed to get listed that way. (I think it would be \nmore clear to list merges of depended-on series rather than the contents \nof the series, when the depended-on series is also listed)\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"42593","messageId":"7vd50xz7lq.fsf@assigned-by-dhcp.cox.net","threadId":"8139","inReplyTo":"7vfy5wcnbg.fsf@assigned-by-dhcp.cox.net","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-19T05:48:49Z","receivedAt":"2007-05-19T05:48:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking.  Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'.  The topics list the commits in reverse chronological\norder.\n\n------------------------\nTo graduate immediately after 1.5.2, after 'maint' forks from\nit.\n\n* jb/statcolor (Sat May 5 16:48:54 2007 -0400) 1 commit\n + Add colour support in rebase and merge tree diff stats output.\n\n* tt/gc (Wed May 9 15:48:39 2007 -0400) 1 commit\n + Add --aggressive option to 'git gc'\n\n* np/pack (Wed May 9 14:42:42 2007 -0400) 3 commits\n + deprecate the new loose object header format\n + make \"repack -f\" imply \"pack-objects --no-reuse-object\"\n + allow for undeltified objects not to be reused\n\n* sv/checkout (Wed May 9 12:33:20 2007 +0200) 1 commit\n + git-update-ref: add --no-deref option for overwriting/detaching\n   ref\n\n* mst/connect (Wed May 16 20:09:41 2007 +0300) 1 commit\n + connect: display connection progress\n\n* dh/pack (Wed May 9 13:56:50 2007 -0700) 3 commits\n + Custom compression levels for objects and packs\n + make \"repack -f\" imply \"pack-objects --no-reuse-object\"\n + allow for undeltified objects not to be reused\n\n------------------------\nTo be re-reviewed and then merged to 'next' after 1.5.2.\n\n* db/remote (Tue May 15 22:50:19 2007 -0400) 5 commits\n - Update local tracking refs when pushing\n - Add handlers for fetch-side configuration of remotes.\n - Move refspec parser from connect.c and cache.h to remote.{c,h}\n - Move remote parsing into a library file out of builtin-push.\n\n* dh/repack (Sun May 13 12:47:09 2007 -0700) 9 commits\n - git-repack --max-pack-size: add option parsing to enable feature\n - git-repack --max-pack-size: split packs as asked by\n   write_{object,one}()\n - git-repack --max-pack-size: write_{object,one}() respect pack\n   limit\n - git-repack --max-pack-size: new file statics and code\n   restructuring\n - Alter sha1close() 3rd argument to request flush only\n\n------------------------\nI've queued this series only because I trust Pasky, not because I\nlooked at the code deeply.  I am not sure about this one's use\nof JavaScript is acceptable (I haven't looked at the code and do\nnot even know if that is optional X-<  Yes, I know, My Bad).\n\n* pb/web (Sat May 19 02:13:39 2007 +0200) 6 commits\n - gitweb: Clearly distinguish regexp / exact match searches\n - gitweb: Lift any characters restriction on searched strings\n - git-rev-list: Add regexp tuning options\n - gitweb: Remove git_blame (superseded by git_blame2)\n - gitweb: Extra columns in blame\n - gitweb: Incremental blame\n\n------------------------\nOn hold.\n\n* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits\n - blame: show log as it goes\n - git-blame: optimize get_origin() from linear search to hash-\n   lookup.\n - git-blame: pass \"struct scoreboard *\" pointers around.\n - blame: lift structure definitions up\n\n* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits\n - test-para: combined diff between HEAD, index and working tree.\n - para-walk: walk n trees, index and working tree in parallel\n"},{"id":"43054","messageId":"7vodkb1adr.fsf@assigned-by-dhcp.cox.net","threadId":"8139","inReplyTo":"7vd50xz7lq.fsf@assigned-by-dhcp.cox.net","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-23T21:46:24Z","receivedAt":"2007-05-23T21:46:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nothing controversial has been queued since v1.5.2 yet.\n\nHere are the topics that have been cooking.  Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'.  The topics list the commits in reverse chronological\norder.\n\n* fl/cvsserver (Mon May 21 00:31:58 2007 +0200) 3 commits\n + t9400: Add some basic pserver tests\n + t9400: Add some more cvs update tests\n + t9400: Add test cases for config file handling\n\nWill push this out on 'master' by the end of this week.\n\n* dh/repack (Wed May 23 10:11:33 2007 -0700) 6 commits\n + pack-objects: clarification & option checks for --max-pack-size\n + git-repack --max-pack-size: add option parsing to enable feature\n + git-repack --max-pack-size: split packs as asked by\n   write_{object,one}()\n + git-repack --max-pack-size: write_{object,one}() respect pack\n   limit\n + git-repack --max-pack-size: new file statics and code\n   restructuring\n + Alter sha1close() 3rd argument to request flush only\n\nI've commented on this series in a separate message.  Looks\nquite clean modulo a few minor details, which was fixed up this\nmorning.  Will be in 'master' shortly.\n\n* db/remote (Tue May 15 22:50:19 2007 -0400) 4 commits\n + Update local tracking refs when pushing\n + Add handlers for fetch-side configuration of remotes.\n + Move refspec parser from connect.c and cache.h to remote.{c,h}\n + Move remote parsing into a library file out of builtin-push.\n\nWill need to look at this once more; I do not expect too much\nproblems with it.\n\n* jc/nodelta (Tue May 22 23:04:49 2007 -0700) 3 commits\n + builtin-pack-objects: remove unnecessary code for no-delta\n + Teach \"delta\" attribute to pack-objects.\n + pack-objects: pass fullname down to add_object_entry()\n\nI am a bit worried about potential performance penalty that can\ncome from attribute look-up on big trees, which I've never\nmeasured so far.  Independent measurement would be very much\nappreciated, and if it turns out to be too bad, we might want to\ndiscard this.\n\nThe remainder is backburnered.\n\n* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits\n* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits\n"},{"id":"43099","messageId":"20070524061521.GK28023@spearce.org","threadId":"8139","inReplyTo":"7vodkb1adr.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-24T06:15:21Z","receivedAt":"2007-05-24T06:15:21Z","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> * db/remote (Tue May 15 22:50:19 2007 -0400) 4 commits\n>  + Update local tracking refs when pushing\n>  + Add handlers for fetch-side configuration of remotes.\n>  + Move refspec parser from connect.c and cache.h to remote.{c,h}\n>  + Move remote parsing into a library file out of builtin-push.\n> \n> Will need to look at this once more; I do not expect too much\n> problems with it.\n\nI spent all day today working with this series.  Lots of pushing new\nbranches, deleting existing branches, updating existing branches\nacross many repositories.  Its an *awesome* change.  I'm really\nhappy with it.\n\n-- \nShawn.\n"},{"id":"43553","messageId":"7virac547s.fsf@assigned-by-dhcp.cox.net","threadId":"8139","inReplyTo":"7vodkb1adr.fsf@assigned-by-dhcp.cox.net","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-29T10:11:51Z","receivedAt":"2007-05-29T10:11:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Tonight's 'next' is broken in that it does not seem to be able\nto do \"git cat-file -t aba170cdb4874b72dd619e6f7bbc13c33295f83\".\nIf you add \"1\" to the end, it becomes the commit v1.5.2^0.\nBisecting shows \"Lazily open pack index files on demand\" is the\nculprit, so I've reverted it locally (and made sure things\nstarts working again), but I haven't got around to pushing out\nthe results yet.  I won't, until tomorrow evening.\n\nI'm a bit tired and it is getting late, so I won't comment on\neach of the series.  I am seriously considering about merging\nPasky's applypatch removal soon to 'master'.\n\n----------------------------------------------------------------\n\nHere are the topics that have been cooking.  Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'.  The topics list the commits in reverse chronological\norder.\n\n* sp/pack (Tue May 29 02:49:08 2007 -0700) 4 commits\n . Revert \"Lazily open pack index files on demand\"\n + Attempt to delay prepare_alt_odb during get_sha1\n + Micro-optimize prepare_alt_odb\n + Lazily open pack index files on demand\n\n* pb/am (Thu May 24 19:25:25 2007 -0700) 2 commits\n + Remove git-applypatch\n + git-applymbox: Remove command\n\n* mk/pack (Mon May 28 23:20:59 2007 +0200) 3 commits\n + builtin-pack-object: cache small deltas\n + git-pack-objects: cache small deltas between big objects\n + builtin-pack-objects: don't fail, if delta is not possible\n\n* lh/submodules (Sat May 26 15:56:40 2007 +0200) 1 commit\n + Add git-submodule command\n\n* dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit\n - Enhance unpack-objects for live repo and large objects\n\n* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits\n - blame: show log as it goes\n - git-blame: optimize get_origin() from linear search to hash-\n   lookup.\n - git-blame: pass \"struct scoreboard *\" pointers around.\n - blame: lift structure definitions up\n\n* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits\n - test-para: combined diff between HEAD, index and working tree.\n - para-walk: walk n trees, index and working tree in parallel\n"},{"id":"43828","messageId":"7v6466oygl.fsf@assigned-by-dhcp.cox.net","threadId":"8139","inReplyTo":"7virac547s.fsf@assigned-by-dhcp.cox.net","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-06-02T21:09:30Z","receivedAt":"2007-06-02T21:09:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Again, 'next' is getting quite lightweight compared to 'master'.\nGood time to do \"war on whitespace\" Marco suggested myself.\n\n'pu' has Shawn's 'pu' from git-gui, to help people experiment\nwith the proposed blame viewer improvements more easily.  I\npersonally like it quite a bit.\n\n----------------------------------------------------------------\n\nHere are the topics that have been cooking.  Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'.  The topics list the commits in reverse chronological\norder.\n\n* lh/submodules (Sat Jun 2 03:27:42 2007 +0200) 2 commits\n + Add basic test-script for git-submodule\n + Add git-submodule command\n\nI find this a 'master' material already.  Will merge soon.\n\n* gb/idx (Fri Jun 1 15:18:05 2007 -0400) 1 commit\n + Unify write_index_file functions\n\nShould graduate to 'master' by mid next week.\n\n* pb/am (Thu May 24 19:25:25 2007 -0700) 2 commits\n + Remove git-applypatch\n + git-applymbox: Remove command\n\nWill push out to 'master' soon to see if anybody screams.\n\n* dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit\n - Enhance unpack-objects for live repo and large objects\n\nI saw nobody other than Dana jump up and down and say we must\nhave this, so I still parked this in 'pu' without merging it to\n'next'.  Maybe a time for a quick poll?\n\n* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits\n - blame: show log as it goes\n - git-blame: optimize get_origin() from linear search to hash-\n   lookup.\n - git-blame: pass \"struct scoreboard *\" pointers around.\n - blame: lift structure definitions up\n\n* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits\n - test-para: combined diff between HEAD, index and working tree.\n - para-walk: walk n trees, index and working tree in parallel\n\nBackburnered.  Further work on the latter, or something like\nthat, or something based on (disused) git-merge-tree, is needed\nto exonerate Linus from having lied in the following part of his\ntalk (there is a transcript at http://git.or.cz/gitwiki of his\ntalk by the way):\n\n    The source code may sometimes look complicated because we\n    are very performance centric, I am.  I really care, and\n    sometimes to make things go really fast, you have to use\n    more complicated algorithms than just checking one file at a\n    time.  When you are doing 22,000 file merges, you do not\n    want to check one file at a time, you want to check the\n    whole tree in one go and say, \"Ah they are the same, I do\n    not have to do anything\".\n\nas we _DO_ currently merge one path at a time.\n\nYou _could_ interpret \"merge\" in his message as applying\nmillions of patches from Andrew, in which case it is true ---\nthe cache-tree optimization in the index does help us skipping\nthe unchanged tree recomputation.  But that does not apply to a\ntrue merge, even when it is a trivial tree-level merge.\n"},{"id":"43838","messageId":"Pine.LNX.4.64.0706030114540.4046@racer.site","threadId":"8139","inReplyTo":"7v6466oygl.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-03T00:20:51Z","receivedAt":"2007-06-03T00:20:51Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 2 Jun 2007, Junio C Hamano wrote:\n\n> * lh/submodules (Sat Jun 2 03:27:42 2007 +0200) 2 commits\n>  + Add basic test-script for git-submodule\n>  + Add git-submodule command\n> \n> I find this a 'master' material already.  Will merge soon.\n\nI agree. Even if I had not time to review it closely, from a cursory look \nit is clean enough. I don't expect any regressions from that.\n\n> * pb/am (Thu May 24 19:25:25 2007 -0700) 2 commits\n>  + Remove git-applypatch\n>  + git-applymbox: Remove command\n> \n> Will push out to 'master' soon to see if anybody screams.\n\nAck.\n\n> * jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits\n>  - test-para: combined diff between HEAD, index and working tree.\n>  - para-walk: walk n trees, index and working tree in parallel\n> \n> Backburnered.\n\nI actually like those two commits, and I always wanted to work on top of \nthese, but my new boss keeps me away from Git :-(\n\nWill review, and try to work some more on them in the next three weeks. \nDon't drop them!\n\nAs for the complicated source code: I cannot agree. If you have _any_ idea \nabout what data structures are about, you will readily recognize what it \nis about. We _could_ be more explicit, but by a huge margin.\n\n(IMHO too many people try to chime in without _any_ clue about the \ndifference of hash tables and binary search, and no notion of Landau's \nsymbol. We should not necessarily try to accomodate people who are _that_ \nunwilling to work up their theory.)\n\nCiao,\nDscho\n"},{"id":"43844","messageId":"20070603011026.GB4507@spearce.org","threadId":"8139","inReplyTo":"7v6466oygl.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-06-03T01:10:26Z","receivedAt":"2007-06-03T01:10:26Z","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> 'pu' has Shawn's 'pu' from git-gui, to help people experiment\n> with the proposed blame viewer improvements more easily.  I\n> personally like it quite a bit.\n\nFor what its worth, my 'pu' has the same policy as Junio's; it\nrebases freely and topics can come and go from it at any time.\nBut that said, it is certainly suitable for Junio's 'pu'.  :-)\n\nI just pushed an even newer version out a couple of minutes ago.\nNow I'm running two passes of git-blame:\n\n\t*) Pass 1:  git-blame --incremental\n\t*) Pass 2:  git-blame -M -C -C --incremental\n\nand the viewer shows them in two columns.  This gives you pretty\nquick information about why a change exists, as you get both who\nmoved the block to where it is, and who originally wrote it.  ;-)\n\nLots of things still to be worked on in blame, like having it\nkeep track of what line(s) you are at or are trying to jump to.\nI'll try to get to that stuff tonight or tomorrow.\n\n-- \nShawn.\n"},{"id":"43910","messageId":"alpine.LFD.0.99.0706031703140.12885@xanadu.home","threadId":"8139","inReplyTo":"7v6466oygl.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-06-03T21:06:04Z","receivedAt":"2007-06-03T21:06:04Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Sat, 2 Jun 2007, Junio C Hamano wrote:\n\n> * dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit\n>  - Enhance unpack-objects for live repo and large objects\n> \n> I saw nobody other than Dana jump up and down and say we must\n> have this, so I still parked this in 'pu' without merging it to\n> 'next'.  Maybe a time for a quick poll?\n\nI did provide a followup comment to this patch.  If the concerns I \nraised are addressed then I won't be against such a patch.\n\n\nNicolas\n"},{"id":"43912","messageId":"56b7f5510706031420j153f5f36v64e296b3f098f38@mail.gmail.com","threadId":"8139","inReplyTo":"alpine.LFD.0.99.0706031703140.12885@xanadu.home","subject":"Re: What's cooking in git.git (topics)","fromName":"Dana How","fromEmail":"danahow@gmail.com","sentAt":"2007-06-03T21:20:43Z","receivedAt":"2007-06-03T21:20:43Z","isPatch":false,"sender":{"key":"danahow@gmail.com","avatar":null},"body":"On 6/3/07, Nicolas Pitre <nico@cam.org> wrote:\n> On Sat, 2 Jun 2007, Junio C Hamano wrote:\n> > * dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit\n> >  - Enhance unpack-objects for live repo and large objects\n> >\n> > I saw nobody other than Dana jump up and down and say we must\n> > have this, so I still parked this in 'pu' without merging it to\n> > 'next'.  Maybe a time for a quick poll?\n>\n> I did provide a followup comment to this patch.  If the concerns I\n> raised are addressed then I won't be against such a patch.\n\nHmm, I thought only your comments about incoherency were\nstill unaddressed and they applied only to the degunking patch,\nbut in any case I was planning to improve both patches in similar ways.\nI won't be able to do this for a week or two (crunch time here).\nI will first review the discussion for each patch in case my memory is wrong.\n\nThanks,\n-- \nDana L. How  danahow@gmail.com  +1 650 804 5991 cell\n"},{"id":"44212","messageId":"7vfy54tt3l.fsf@assigned-by-dhcp.cox.net","threadId":"8139","inReplyTo":"7v6466oygl.fsf@assigned-by-dhcp.cox.net","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-07T02:07:42Z","receivedAt":"2007-06-07T02:07:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Probably a few topics from the following will graduate to\n'master' this weekend, but otherwise I expect that I'll be\nextremely slow and won't be doing much git next week.\n\nHere are the topics that have been cooking.  Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'.  The topics list the commits in reverse chronological\norder.\n\n\"pu\" also contains \"pu\" from git-gui as of tonight.\n\n* ar/clone (Wed Jun 6 16:39:05 2007 -0700) 1 commit\n - Fix clone to setup the origin if its name ends with .git\n\nThis is meant to be merged to 'maint' as part of 1.5.2.2, but I\nam taking things slowly.\n\n* js/merge (Tue Jun 5 03:37:13 2007 +0100) 1 commit\n + git-merge-file: refuse to merge binary files\n\nThis series needs to be cherry-picked to 'maint' at some point.\n\n* js/filter (Wed Jun 6 20:38:35 2007 +0200) 8 commits\n + filter-branch: also don't fail in map() if a commit cannot be\n   mapped\n + filter-branch: Use rev-list arguments to specify revision ranges.\n + filter-branch: fix behaviour of '-k'\n + filter-branch: use $(($i+1)) instead of $((i+1))\n + chmod +x git-filter-branch.sh\n + filter-branch: prevent filters from reading from stdin\n + t7003: make test repeatable\n + Add git-filter-branch\n\nJohannes & Johannes work well together ;-).  Will push out to\n'master' shortly.\n\n* lh/submodule (Wed Jun 6 11:13:02 2007 +0200) 2 commits\n + git-submodule: clone during update, not during init\n + git-submodule: move cloning into a separate function\n\nWill push out to 'master' shortly.\n\n* aj/pack (Sun Jun 3 20:21:41 2007 +0200) 1 commit\n + pack-check: Sort entries by pack offset before unpacking them.\n\nMakes \"git fsck --full\" go a lot faster.  Will push out to\n'master' shortly.\n\n* aw/cvs (Mon Jun 4 10:01:49 2007 +0100) 3 commits\n + cvsimport: add <remote>/HEAD reference in separate remotes more\n + cvsimport: update documentation to include separate remotes option\n + cvsimport: add support for new style remote layout\n\nMakes the ref layout consistent with git managed branches;\ngit-svn already does this, I think.\n\n* ep/cvstag (Sun Jun 3 02:56:36 2007 -0400) 1 commit\n + Use git-tag in git-cvsimport\n\nInstead of handrolling a tag using lower-level mktag, this uses\ngit-tag.\n\n* jh/tag (Mon Jun 4 02:54:56 2007 +0200) 6 commits\n + Add fsck_verify_ref_to_tag_object() to verify that refname matches\n   name stored in tag object\n + git-mktag tests: Fix and expand the mktag tests according to the\n   new tag object structure\n + Documentation/git-mktag: Document the changes in tag object\n   structure\n + git-fsck: Do thorough verification of tag objects.\n + git-show: When showing tag objects with no tag name, show tag\n   object's SHA1 instead of an empty string\n + Refactor git tag objects; make \"tag\" header optional; introduce\n   new optional \"keywords\" header\n\nTag refactoring.  Looking good.\n\n* ml/worktree (Wed Jun 6 23:29:59 2007 +0200) 8 commits\n - setup_git_directory: fix segfault if repository is found in cwd\n - test GIT_WORK_TREE\n - extend rev-parse test for --is-inside-work-tree\n - Use new semantics of is_bare/inside_git_dir/inside_work_tree\n - introduce GIT_WORK_TREE to specify the work tree\n - test git rev-parse\n - rev-parse: introduce --is-bare-repository\n - rev-parse: document --is-inside-git-dir\n\nAllows you to have GIT_DIR environment that points at a\nrepository at an unrelated location, and still lets you work in\na working tree subdirectory by pointing its root with another\nenvironment variable.  It is an intrusive set of changes.\n\n* ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200) 1 commit\n - filter-branch: always export GIT_DIR if it is set\n\nThis is \"early integration\" that depends on two other topics\n(GIT_WORK_TREE and filter-branch).  This needs to be merged when\nboth topics graduate to 'master'.\n\n* dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit\n - Enhance unpack-objects for live repo and large objects\n\n* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits\n - blame: show log as it goes\n - git-blame: optimize get_origin() from linear search to hash-\n   lookup.\n - git-blame: pass \"struct scoreboard *\" pointers around.\n - blame: lift structure definitions up\n\n* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits\n - test-para: combined diff between HEAD, index and working tree.\n - para-walk: walk n trees, index and working tree in parallel\n"},{"id":"44999","messageId":"7vtztbbnsq.fsf@assigned-by-dhcp.pobox.com","threadId":"8139","inReplyTo":"7vfy54tt3l.fsf@assigned-by-dhcp.cox.net","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-13T20:29:57Z","receivedAt":"2007-06-13T20:29:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking.  Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'.  The topics list the commits in reverse chronological\norder.\n\n* lh/submodule (Tue Jun 12 09:05:21 2007 +0200) 5 commits\n + Add gitmodules(5)\n + git-submodule: give submodules proper names\n + Rename sections from \"module\" to \"submodule\" in .gitmodules\n + git-submodule: remember to checkout after clone\n + t7400: barf if git-submodule removes or replaces a file\n\nSoon to be merged to 'master' as 1.5.3 material, but still needs a\ntrivial fix to the Documentation/gitmodules.txt, though.\n\n* js/filter (Fri Jun 8 23:28:50 2007 +0200) 11 commits\n + filter-branch: subdirectory filter needs --full-history\n + filter-branch: Simplify parent computation.\n + Teach filter-branch about subdirectory filtering\n + filter-branch: also don't fail in map() if a commit cannot be\n   mapped\n + filter-branch: Use rev-list arguments to specify revision ranges.\n + filter-branch: fix behaviour of '-k'\n + filter-branch: use $(($i+1)) instead of $((i+1))\n + chmod +x git-filter-branch.sh\n + filter-branch: prevent filters from reading from stdin\n + t7003: make test repeatable\n + Add git-filter-branch\n\nSoon to be merged to 'master' as 1.5.3 material, but still needs\ndocumentation, and culling of empty side branches.\n\n* fl/cvsserver (Thu Jun 7 16:57:01 2007 +0200) 1 commit\n + cvsserver: Add some useful commandline options\n\nTo merge.\n\n* gp/branch (Sat Jun 9 12:40:35 2007 +0000) 1 commit\n + git-branch: cleanup config file when deleting branches\n\nTo merge.\n\n* jc/remote (Sat Jun 9 11:01:23 2007 -0700) 6 commits\n + git-push: Update description of refspecs and add examples\n + remote.c: \"git-push frotz\" should update what matches at the\n   source.\n + remote.c: fix \"git push\" weak match disambiguation\n + remote.c: minor clean-up of match_explicit()\n + remote.c: refactor creation of new dst ref\n + remote.c: refactor match_explicit_refs()\n\nTo merge; this is an fix to fairly annoying breakage.\n\n* ew/svn (Wed Jun 13 02:23:28 2007 -0700) 1 commit\n + git-svn: allow dcommit to retain local merge information\n\nHoping to be able to merge it to 'master', as it would be a big\nusability improvement for people who use \"git to merge because\nSVN cannot\" (without this, life ater such a merge will\nunfortunately be miserable).\n\n* jk/add-empty (Tue Jun 12 23:42:14 2007 +0200) 2 commits\n + builtin-add: simplify (and increase accuracy of) exclude handling\n + dir_struct: add collect_ignored option\n\nHoping to be able to merge them to 'master', but haven't\nconvinced myself that these changes are correct.  Help is\nappreciated.\n\n* jc/oneline (Mon Jun 11 22:10:55 2007 -0700) 2 commits\n + Extend --pretty=oneline to cover the first paragraph,\n + Lift 16kB limit of log message output\n\nHoping to be able to merge them to 'master', but haven't\nconvinced myself that these changes are correct.  Help is\nappreciated.\n\n* jo/init (Thu Jun 7 07:50:30 2007 -0500) 2 commits\n - Quiet the output from git-init when cloning, if requested.\n - Add an option to quiet git-init.\n\nUndecided.  I do not have anything against these two patches, as\nthey are obviously correct.  It's just the fact that nobody\ncomplained my keeping these packed on 'pu' suggests there is not\nmuch desire, and it is an extra option we need to maintain.\n\n* ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200)\n - filter-branch: always export GIT_DIR if it is set\n* ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits\n - make git barf when an alias changes environment variables\n - setup_git_directory: fix segfault if repository is found in cwd\n - test GIT_WORK_TREE\n - extend rev-parse test for --is-inside-work-tree\n - Use new semantics of is_bare/inside_git_dir/inside_work_tree\n - introduce GIT_WORK_TREE to specify the work tree\n - test git rev-parse\n - rev-parse: introduce --is-bare-repository\n - rev-parse: document --is-inside-git-dir\n\nUndecided.  Some people would want to have a way to have GIT_DIR\npoint at somewhere unusual and still want to work from within a\nsubdirectory, which is probably a valid thing to support.  This\nis not something I would use myself, so I am mostly worried\nabout the impact these changes may have on people who do not use\nthis feature.\n"},{"id":"45013","messageId":"Pine.LNX.4.64.0706132334060.4059@racer.site","threadId":"8139","inReplyTo":"7vtztbbnsq.fsf@assigned-by-dhcp.pobox.com","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-06-13T22:44:01Z","receivedAt":"2007-06-13T22:44:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 13 Jun 2007, Junio C Hamano wrote:\n\n> * js/filter (Fri Jun 8 23:28:50 2007 +0200) 11 commits\n\nIsn't that convenient? That's already the second project the two JS'es are \nworking together...\n\n> * jc/oneline (Mon Jun 11 22:10:55 2007 -0700) 2 commits\n>  + Extend --pretty=oneline to cover the first paragraph,\n>  + Lift 16kB limit of log message output\n> \n> Hoping to be able to merge them to 'master', but haven't\n> convinced myself that these changes are correct.  Help is\n> appreciated.\n\nI haven't had a chance to look at the patch yet, but the intention is \nsound.\n\n> * ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200)\n>  - filter-branch: always export GIT_DIR if it is set\n> * ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits\n>  - make git barf when an alias changes environment variables\n>  - setup_git_directory: fix segfault if repository is found in cwd\n>  - test GIT_WORK_TREE\n>  - extend rev-parse test for --is-inside-work-tree\n>  - Use new semantics of is_bare/inside_git_dir/inside_work_tree\n>  - introduce GIT_WORK_TREE to specify the work tree\n>  - test git rev-parse\n>  - rev-parse: introduce --is-bare-repository\n>  - rev-parse: document --is-inside-git-dir\n> \n> Undecided.  Some people would want to have a way to have GIT_DIR\n> point at somewhere unusual and still want to work from within a\n> subdirectory, which is probably a valid thing to support.  This\n> is not something I would use myself, so I am mostly worried\n> about the impact these changes may have on people who do not use\n> this feature.\n\nYeah, it is something to worry about. As far as I am concerned, these \nchanges are too deep for too obscure a feature.\n\nBut then, I see that people need it.\n\nAnd I can't think of a better way to implement it. So unless somebody \ncomes up with a nice solution, I think we should live with it, rather than \nlet it simmer in pu.\n\nCiao,\nDscho\n"},{"id":"45034","messageId":"alpine.LFD.0.98.0706132013240.14121@woody.linux-foundation.org","threadId":"8139","inReplyTo":"Pine.LNX.4.64.0706132334060.4059@racer.site","subject":"Re: What's cooking in git.git (topics)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-14T03:18:58Z","receivedAt":"2007-06-14T03:18:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 13 Jun 2007, Johannes Schindelin wrote:\n> \n> > * js/filter (Fri Jun 8 23:28:50 2007 +0200) 11 commits\n> \n> Isn't that convenient?\n\nHeh. I heard a perfect Dana Carvey \"Isn't that conveeenient\" in my head on \nthat line (SNL \"Church Lady\" skits, in case people don't make the \nconnection).\n\nWas that intentional, or is it just my brain that is fried?\n\n\"Isn't that speecial?\"\n\n> That's already the second project the two JS'es are working together...\n\nThere's clearly something deeper to this notion of two-letter naming that \nJunio uses.  I used to think it was obviously flawed, but Junio may really \nbe onto something here..\n\n\t\t\tLinus\n"},{"id":"45274","messageId":"20070618172044.GA1197@moooo.ath.cx","threadId":"8139","inReplyTo":"7vtztbbnsq.fsf@assigned-by-dhcp.pobox.com","subject":"Re: What's cooking in git.git (topics)","fromName":"Matthias Lederhofer","fromEmail":"matled@gmx.net","sentAt":"2007-06-18T17:20:44Z","receivedAt":"2007-06-18T17:20:44Z","isPatch":false,"sender":{"key":"matled@gmx.net","avatar":null},"body":"Junio C Hamano <gitster@pobox.com> wrote:\n> * ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200)\n>  - filter-branch: always export GIT_DIR if it is set\n> * ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits\n>  - make git barf when an alias changes environment variables\n>  - setup_git_directory: fix segfault if repository is found in cwd\n>  - test GIT_WORK_TREE\n>  - extend rev-parse test for --is-inside-work-tree\n>  - Use new semantics of is_bare/inside_git_dir/inside_work_tree\n>  - introduce GIT_WORK_TREE to specify the work tree\n>  - test git rev-parse\n>  - rev-parse: introduce --is-bare-repository\n>  - rev-parse: document --is-inside-git-dir\n> \n> Undecided.  Some people would want to have a way to have GIT_DIR\n> point at somewhere unusual and still want to work from within a\n> subdirectory, which is probably a valid thing to support.  This\n> is not something I would use myself, so I am mostly worried\n> about the impact these changes may have on people who do not use\n> this feature.\n\nThe only problem I know of up to now seems the one which happened with\ngit-filter-branch: if GIT_DIR is set and GIT_WORK_TREE/core.worktree is\nset the specified working tree is used instead of cwd.\n\nSo for users not using GIT_WORK_TREE/core.worktree there should be no\nproblem.  There might be problems if someone distributes scripts for\ngit which expect the old behaviour and the user specified the\nworktree.  OTOH the fix is to export GIT_WORK_TREE=. which does not\nbreak the script for older versions of git versions and is quite\nshort (i.e. should not require any restructuring of the script).\n"},{"id":"45476","messageId":"7v4pl1zsd7.fsf@assigned-by-dhcp.pobox.com","threadId":"8139","inReplyTo":"7vtztbbnsq.fsf@assigned-by-dhcp.pobox.com","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-21T07:20:04Z","receivedAt":"2007-06-21T07:20:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking.  Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'.  The topics list the commits in reverse chronological\norder.\n\n* lt/follow (Tue Jun 19 14:22:46 2007 -0700) 1 commit\n + Finally implement \"git log --follow\"\n\nHas leaks, and it won't graduate to 'master' without\ndocumentation.\n\nAlso I am not convinced its handling of merges is sane.  If you\nhave an ancestry graph like this, and the commit A renames the\nfollowed path, it would show the file _before_ rename, which is\nvery good.\n\n      o-------B---A---o----o\n                     /  \n        o----C------'\n    \nBut the code changes pathspec globally, so when we are looking\nat C, it may or may not have that (before-renamed) path there.\n\nAt least, the patch is small and would not affect codepath that\ndoes not use this option, so in that sense it is relatively safe\nchange, though.\n\n* jc/oneline (Fri Jun 15 13:19:07 2007 +0100) 4 commits\n + pp_header(): work around possible memory corruption\n + Fix ALLOC_GROW off-by-one\n + Extend --pretty=oneline to cover the first paragraph,\n + Lift 16kB limit of log message output\n* jk/add-empty (Tue Jun 12 23:42:14 2007 +0200) 2 commits\n + builtin-add: simplify (and increase accuracy of) exclude handling\n + dir_struct: add collect_ignored option\n\nWill merge this weekend.\n\n* ns/clone (Sat Jun 16 15:26:08 2007 -0700) 1 commit\n + Cloning from a repo without \"current branch\"\n\nWill merge this weekend.\n\n* js/filter (Fri Jun 8 23:28:50 2007 +0200) 11 commits\n + filter-branch: subdirectory filter needs --full-history\n + filter-branch: Simplify parent computation.\n + Teach filter-branch about subdirectory filtering\n + filter-branch: also don't fail in map() if a commit cannot be\n   mapped\n + filter-branch: Use rev-list arguments to specify revision ranges.\n + filter-branch: fix behaviour of '-k'\n + filter-branch: use $(($i+1)) instead of $((i+1))\n + chmod +x git-filter-branch.sh\n + filter-branch: prevent filters from reading from stdin\n + t7003: make test repeatable\n + Add git-filter-branch\n\nWill merge this weekend.\n\n* ew/svn (Wed Jun 13 02:23:28 2007 -0700) 1 commit\n + git-svn: allow dcommit to retain local merge information\n\nHaven't heard major breakage report, so hopefully can merge by\nthe end of the month.\n\n* ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits\n + make git barf when an alias changes environment variables\n + setup_git_directory: fix segfault if repository is found in cwd\n + test GIT_WORK_TREE\n + extend rev-parse test for --is-inside-work-tree\n + Use new semantics of is_bare/inside_git_dir/inside_work_tree\n + introduce GIT_WORK_TREE to specify the work tree\n + test git rev-parse\n + rev-parse: introduce --is-bare-repository\n + rev-parse: document --is-inside-git-dir\n\nI've been resisting this but I think its definition of is-bare\nis a bit saner than what we have in 'master', and I think it is\nthe right direction in the longer term.  HOWEVER, I am not sure\nabout the implementation and corner cases, e.g. what should it\ndo in receive-pack?  You cannot rely on user setting GIT_WORK_TREE\nenvironment -- rather, receive-pack is responsible for setting\nup a sane environment for other commands to work in.\n\n* jo/init (Thu Jun 7 07:50:30 2007 -0500) 2 commits\n - Quiet the output from git-init when cloning, if requested.\n - Add an option to quiet git-init.\n"},{"id":"45518","messageId":"alpine.LFD.0.98.0706211005520.3593@woody.linux-foundation.org","threadId":"8139","inReplyTo":"7v4pl1zsd7.fsf@assigned-by-dhcp.pobox.com","subject":"Re: What's cooking in git.git (topics)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-21T17:16:46Z","receivedAt":"2007-06-21T17:16:46Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 21 Jun 2007, Junio C Hamano wrote:\n> \n> Also I am not convinced its handling of merges is sane.  If you\n> have an ancestry graph like this, and the commit A renames the\n> followed path, it would show the file _before_ rename, which is\n> very good.\n> \n>       o-------B---A---o----o\n>                      /  \n>         o----C------'\n\nI agree. That's even what I tried to explain (but your graph is better) in \nmy commit message, when I was talking about how it linearizes the history \nin \"git log\" order, and decides that renames happen \"within that \nlinearized\" world.\n\nYou can actually see an *example* of this by doing\n\n\tgit log --stat --follow arch/i386/pci/common.c\n\non the old historical Linux archive (the BK import one, not the bkcvs \nimport - the latter has been linearized by bkcvs so won't show concurrent \ndevelopment anyway). \n\nWhat you get is:\n\n\t[ ... ]\n\n\tcommit f9001d4262148fbfb7ecdcb88c73d9791c1ac0ad\n\tAuthor: Greg Kroah-Hartman <greg@kroah.com>\n\tDate:   Mon May 6 20:18:16 2002 -0700\n\t\n\t    Move arch/i386/kernel/pci/ to arch/i386/pci/\n\t\n\t arch/i386/{kernel => }/pci/common.c |    0\n\t 1 files changed, 0 insertions(+), 0 deletions(-)\n\t\n\tcommit bbb283cca10b2d2c935ae35327620ebae07f7d80\n\tAuthor: Patrick Mochel <mochel@segfault.osdl.org>\n\tDate:   Mon May 6 20:09:44 2002 -0700\n\t\n\t    Move arch/i386/kernel/pci/ to arch/i386/pci/\n\t\n\t arch/i386/kernel/pci/common.c |  206 -----------------------------------------\n\t 1 files changed, 0 insertions(+), 206 deletions(-)\n\n\t[ ... ]\n\nand this is an artifact of two _concurrent_ directory moves, and look at \nwhat \"git log --follow\" did: it actually found the rename (we looked at \nGreg's version first), but then *because* it found the rename, it is now \nstarting to look at the *previous* name, which was\n\n\tarch/i386/kernel/pci/common.c\n\nand when it then sees the rename in Pat's commit, it's no longer finding \nthat previous entry as a \"new file that got created\" (which triggers the \nrename logic), but now it finds that filename has being *removed* (because \nthe _old_ filename really did go away - it got renamed!)\n\nThis is 100% logical within that linearized history, but it's a bit \nsurprising. But it's how \"git log --follow\" just works.\n\nIf you want to see the real history, you need to do it with \"git blame\", \nwhich actually understands about merges, or with some graphical viewer \nthat would be extended to follow renames when it notices that a filename \ngoes away.\n\nBut \"git log\" itself really fundamentally has no clue, and you really \nshould see \"git log\" as a *linearization* thing. It linearizes the history \nby creating a one-dimensional streaming log. And within that linearized \nhistory, there can not be anything like \"concurrent renames\".\n\n\t\t\tLinus\n"},{"id":"45520","messageId":"alpine.LFD.0.98.0706211034500.3593@woody.linux-foundation.org","threadId":"8139","inReplyTo":"alpine.LFD.0.98.0706211005520.3593@woody.linux-foundation.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-06-21T17:44:05Z","receivedAt":"2007-06-21T17:44:05Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 21 Jun 2007, Linus Torvalds wrote:\n> \n> But \"git log\" itself really fundamentally has no clue, and you really \n> should see \"git log\" as a *linearization* thing. It linearizes the history \n> by creating a one-dimensional streaming log. And within that linearized \n> history, there can not be anything like \"concurrent renames\".\n\nBtw, just to clarify:\n\n\tThis is absolutely not somethign unique to \"--follow\" and rename \n\tdetection!\n\nwhen you do a simple \"git log -p\", you will very commonly see the issue of \nthe same patch being applied twice, and if you think of the linearized \n\"git log\" output is somehow \"the Truth\" with a capital \"T\", then you'd \nobviously believe that the thing shows up twice in the end result.\n\nIt doesn't even have to be the same patch: you can have a patch that shows \nup in one branch, and that *never* makes it into the end result, even \nthough the other branch didn't \"undo\" it. A merge may have chosen just the \none side (not necessarily due to \"-s ours\" or anythign like that: a merge \nconflict may have been resoled that way). \n\nSo the individual logs of changes are not \"meaningful\" in that sense. Not \nwith --follow, and not without. They are a locally linearized version of \nhistory, and as such you cannot put the world together just based on them. \nYou need to have the bigger picture to get the end result.\n\nDoes that mean that linearization is meaningless? No, obviously not. Does \nit mean that you *can* get confused by it? Yes, absolutely. Does rename \ndetection add new _ways_ of getting confused? Oh, YES! The example from \nthe kernel is a great one.\n\nI still think \"git log --follow\" is actually a really good thing. People \nwill find places like this where they are confused, and maybe we'll have \nto teach them about the effects of linearizing their history, but \nespecially if you come from the CVS/SVN world, your history has _always_ \nbeen linear, so git will always get that case right. \n\nAnd once you get used to merges, you'll start understanding why git does \nwhat git does more, and then the \"git log --follow\" behaviour will still \nperhaps not be what you might always want at any particular point in time, \nbut it's something you can understand and deal with.\n\nAnd it's still hugely preferable to \"file identities\", which have their \nown (and much more fundamental) problems over merges.\n\n\t\tLinus\n"},{"id":"45757","messageId":"7v645cz7vm.fsf@assigned-by-dhcp.pobox.com","threadId":"8139","inReplyTo":"7v4pl1zsd7.fsf@assigned-by-dhcp.pobox.com","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-25T09:43:57Z","receivedAt":"2007-06-25T09:43:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking.  Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'.  The topics list the commits in reverse chronological\norder.\n\n* js/rebase (Mon Jun 25 01:11:14 2007 +0100) 2 commits\n + Teach rebase an interactive mode\n + Move the pick_author code to git-sh-setup\n\nWill merge.\n\n* rs/diff (Mon Jun 25 00:23:34 2007 +0200) 2 commits\n + diff: round down similarity index\n + diffcore-rename: don't change similarity index based on basename\n   equality\n\nWill merge.\n\n* lt/run (Sun Jun 24 10:29:33 2007 -0700) 2 commits\n + Check for IO errors after running a command\n + Clean up internal command handling\n\nWill merge.\n\n* ew/svn (Wed Jun 13 02:23:28 2007 -0700) 1 commit\n + git-svn: allow dcommit to retain local merge information\n\nHaven't heard major breakage report, so hopefully can merge by\nthe end of the month.\n\n* mk/svn (Fri Jun 22 11:15:03 2007 +0200) 1 commit\n - git-svn: honor ~/.subversion/ client cert file settings.\n\nWaiting for ACK from git-svn people.\n\n* ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits\n + make git barf when an alias changes environment variables\n + setup_git_directory: fix segfault if repository is found in cwd\n + test GIT_WORK_TREE\n + extend rev-parse test for --is-inside-work-tree\n + Use new semantics of is_bare/inside_git_dir/inside_work_tree\n + introduce GIT_WORK_TREE to specify the work tree\n + test git rev-parse\n + rev-parse: introduce --is-bare-repository\n + rev-parse: document --is-inside-git-dir\n* ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200) 9 commits\n + filter-branch: always export GIT_DIR if it is set\n\nI've been resisting these due to the size of the series, but I\nthink the definition of is-bare is a bit saner than what we have\nin 'master', and I think it is the right direction in the longer\nterm.  HOWEVER, I am not sure about the implementation and\ncorner cases, e.g. what should it do in receive-pack?  You\ncannot rely on user setting GIT_WORK_TREE environment -- rather,\nreceive-pack is responsible for setting up a sane environment\nfor other commands to work in.\n\n* jc/quote (Sun Jun 24 15:11:24 2007 -0700) 1 commit\n + Add core.quotepath configuration variable.\n\nThis will get rid of \"Why is my UTF-8 pathnames are munged\"\ncomplaints.  Will wait for a while, maybe merge after 1.5.3.  I\nbelieve the output from this is still readable by an unpatched\ngit-apply, but I would want to be absolutely sure.\n\n* jo/init (Thu Jun 7 07:50:30 2007 -0500) 2 commits\n - Quiet the output from git-init when cloning, if requested.\n - Add an option to quiet git-init.\n\nI am not very much interested in this but I do not have any\nstrong or otherwise feeling against it either.\n\n* dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit\n - Enhance unpack-objects for live repo and large objects\n* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits\n - blame: show log as it goes\n - git-blame: optimize get_origin() from linear search to hash-\n   lookup.\n - git-blame: pass \"struct scoreboard *\" pointers around.\n - blame: lift structure definitions up\n* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits\n - test-para: combined diff between HEAD, index and working tree.\n - para-walk: walk n trees, index and working tree in parallel\n\nBackburnered.\n"},{"id":"45774","messageId":"1182786420.3821.28.camel@lt21223.campus.dmacc.edu","threadId":"8139","inReplyTo":"7v645cz7vm.fsf@assigned-by-dhcp.pobox.com","subject":"Re: What's cooking in git.git (topics)","fromName":"Jeffrey C. Ollie","fromEmail":"jeff@ocjtech.us","sentAt":"2007-06-25T15:47:00Z","receivedAt":"2007-06-25T15:47:00Z","isPatch":false,"sender":{"key":"jeff@ocjtech.us","avatar":"https://gravatar.com/avatar/95918a1992f277a811c471ae7275f7e4c9d1a2e517ad290bd6aa93b97e8d34f3?d=mp&s=160"},"body":"On Mon, 2007-06-25 at 02:43 -0700, Junio C Hamano wrote:\n>\n> * jo/init (Thu Jun 7 07:50:30 2007 -0500) 2 commits\n>  - Quiet the output from git-init when cloning, if requested.\n>  - Add an option to quiet git-init.\n> \n> I am not very much interested in this but I do not have any\n> strong or otherwise feeling against it either.\n\nIt seems to me that this series is more about \"DWIM\" than anything.  A\nnaïve user would expect \"git clone -q\" to silcence _all_ non-error\noutput. The output \"Initialized empty Git repository in .git/\" that you\nget from \"git init\" isn't an error...\n\nJeff\n"},{"id":"45833","messageId":"20070626133548.GB11504@moooo.ath.cx","threadId":"8139","inReplyTo":"7v645cz7vm.fsf@assigned-by-dhcp.pobox.com","subject":"Re: What's cooking in git.git (topics)","fromName":"Matthias Lederhofer","fromEmail":"matled@gmx.net","sentAt":"2007-06-26T13:35:48Z","receivedAt":"2007-06-26T13:35:48Z","isPatch":false,"sender":{"key":"matled@gmx.net","avatar":null},"body":"Junio C Hamano <gitster@pobox.com> wrote:\n> * ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits\n>  + make git barf when an alias changes environment variables\n>  + setup_git_directory: fix segfault if repository is found in cwd\n>  + test GIT_WORK_TREE\n>  + extend rev-parse test for --is-inside-work-tree\n>  + Use new semantics of is_bare/inside_git_dir/inside_work_tree\n>  + introduce GIT_WORK_TREE to specify the work tree\n>  + test git rev-parse\n>  + rev-parse: introduce --is-bare-repository\n>  + rev-parse: document --is-inside-git-dir\n> * ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200) 9 commits\n>  + filter-branch: always export GIT_DIR if it is set\n> \n> I've been resisting these due to the size of the series, but I\n> think the definition of is-bare is a bit saner than what we have\n> in 'master', and I think it is the right direction in the longer\n> term.  HOWEVER, I am not sure about the implementation and\n> corner cases, e.g. what should it do in receive-pack?  You\n> cannot rely on user setting GIT_WORK_TREE environment -- rather,\n> receive-pack is responsible for setting up a sane environment\n> for other commands to work in.\n\nThanks.  I'll have a look at receive-pack this week.  Is there\nanything in receive-pack yet which helps to use a working tree in the\nhooks?  Or is this something for which the behaviour of git still has\nto be defined?\n"},{"id":"45881","messageId":"7vtzsurvo1.fsf@assigned-by-dhcp.pobox.com","threadId":"8139","inReplyTo":"20070626133548.GB11504@moooo.ath.cx","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-27T02:14:06Z","receivedAt":"2007-06-27T02:14:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthias Lederhofer <matled@gmx.net> writes:\n\n> Thanks.  I'll have a look at receive-pack this week.  Is there\n> anything in receive-pack yet which helps to use a working tree in the\n> hooks?  Or is this something for which the behaviour of git still has\n> to be defined?\n\nI think the behaviour for receive-pack and the environment the\nhooks run in have been pretty well defined.  You start in the\nrepository (the directory $GIT_DIR), GIT_DIR is set and points\nat it.\n\nThe issue is that the introduction of WORK_TREE enviornment and\ncore.worktree mechanism might want to update the semantics.  For\nexample, some people seem to run checkout (or perhaps \"merge\")\nto update the associated working tree.  Can they find out where\nthe root of the working tree is (because they would want to\nchdir to it before saying \"git checkout\"), given the current\nenvironment receive-pack sets up for them?\n\nEarlier we said that people who use only GIT_DIR without\nGIT_WORK_TREE nor core.worktree should get exactly the same\nsemantics with or without the WORK_TREE topic, so the above may\nnot be an issue.\n"},{"id":"45999","messageId":"20070628202321.GA13263@moooo.ath.cx","threadId":"8139","inReplyTo":"7vtzsurvo1.fsf@assigned-by-dhcp.pobox.com","subject":"Re: What's cooking in git.git (topics)","fromName":"Matthias Lederhofer","fromEmail":"matled@gmx.net","sentAt":"2007-06-28T20:23:21Z","receivedAt":"2007-06-28T20:23:21Z","isPatch":false,"sender":{"key":"matled@gmx.net","avatar":null},"body":"Junio C Hamano <gitster@pobox.com> wrote:\n> I think the behaviour for receive-pack and the environment the\n> hooks run in have been pretty well defined.  You start in the\n> repository (the directory $GIT_DIR), GIT_DIR is set and points\n> at it.\n> \n> The issue is that the introduction of WORK_TREE enviornment and\n> core.worktree mechanism might want to update the semantics.  For\n> example, some people seem to run checkout (or perhaps \"merge\")\n> to update the associated working tree.  Can they find out where\n> the root of the working tree is (because they would want to\n> chdir to it before saying \"git checkout\"), given the current\n> environment receive-pack sets up for them?\n>\n> Earlier we said that people who use only GIT_DIR without\n> GIT_WORK_TREE nor core.worktree should get exactly the same\n> semantics with or without the WORK_TREE topic, so the above may\n> not be an issue.\n\nWhen GIT_WORK_TREE/core.worktree are not set the only difference with\nthe patch series should be that cwd may be used as working tree in more\ncases than before.\n\nI think these are the ways git-receive-pack is executed (in normal\nsetups):\n * local pushes: git_connect() unsets GIT_WORK_TREE.\n * ssh: the user might set GIT_WORK_TREE in his shell\n   configuration, .ssh/environments, .ssh/authorized_keys etc.\n   git-receive-pack is then executed with GIT_WORK_TREE set.\n * git-daemon: git-daemon with --enable=receive-pack allows pushing\n   and does not unset GIT_WORK_TREE, so a git-daemon started with\n   GIT_WORK_TREE exported will also have it exported when receive-pack\n   is executed.\n\nI think it makes sense to unset GIT_WORK_TREE when receive-pack is\nstarted.  In the first case GIT_WORK_TREE is unset already and in the\nlatter two cases I don't think we really need to support that\nGIT_WORK_TREE stays exported in the hooks, it could rather happen\naccidentally.\n\nWhen doing more stuff in receive-pack old hooks might stop working\nbreak.\n\nFor example receive-pack could set up GIT_WORK_TREE with a sane\ndefault value if a working tree can be found, i.e.\n    $ export GIT_WORK_TREE=$(dirname $(pwd))\nif the working tree is in the parent directory\n    $ export GIT_WORK_TREE=$(git config core.worktree)\nif core.worktree is set and otherwise GIT_WORK_TREE is not exported.\nThis way hooks can just use GIT_WORK_TREE for the working tree if\nthey don't need anything special.\n"},{"id":"46011","messageId":"7vmyyjmxv8.fsf@assigned-by-dhcp.pobox.com","threadId":"8139","inReplyTo":"20070628202321.GA13263@moooo.ath.cx","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-06-29T00:02:19Z","receivedAt":"2007-06-29T00:02:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthias Lederhofer <matled@gmx.net> writes:\n\n> When doing more stuff in receive-pack old hooks might stop working\n> break.\n>\n> For example receive-pack could set up GIT_WORK_TREE with a sane\n> default value if a working tree can be found, i.e.\n>     $ export GIT_WORK_TREE=$(dirname $(pwd))\n> if the working tree is in the parent directory\n>     $ export GIT_WORK_TREE=$(git config core.worktree)\n> if core.worktree is set and otherwise GIT_WORK_TREE is not exported.\n> This way hooks can just use GIT_WORK_TREE for the working tree if\n> they don't need anything special.\n\nYour analysis looks good.  Probably we can start without doing\nanything to see if anybody screams.\n"},{"id":"46203","messageId":"7vd4zb3bid.fsf@assigned-by-dhcp.cox.net","threadId":"8139","inReplyTo":"7v645cz7vm.fsf@assigned-by-dhcp.pobox.com","subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-02T00:16:58Z","receivedAt":"2007-07-02T00:16:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking in 'next'.\n\n* ns/stash (Sun Jul 1 15:29:01 2007 -0700) 3 commits\n + git-stash: require \"save\" to be explicit and update documentation\n + Document git-stash\n + Add git-stash script\n\nI am hoping this would appear in 1.5.3; it would help what many\npeople asked (and later we probably would want to invoke it in\ngit-merge to have an option to automated the process further).\n\n* js/rebase (Mon Jun 25 18:59:43 2007 +0100) 6 commits\n + Teach rebase -i about --preserve-merges\n + rebase -i: provide reasonable reflog for the rebased branch\n + rebase -i: several cleanups\n + ignore git-rebase--interactive\n + Teach rebase an interactive mode\n + Move the pick_author code to git-sh-setup\n\nWill merge.\n\n* jc/diffcore (Thu Jun 28 23:14:13 2007 -0700) 4 commits\n + diffcore-delta.c: Ignore CR in CRLF for text files\n + diffcore-delta.c: update the comment on the algorithm.\n + diffcore_filespec: add is_binary\n + diffcore_count_changes: pass diffcore_filespec\n\nWill merge; although the CRLF stuff itself would probably not\nhelp anybody in real-life, the change in the interface to allow\nfurther enhancement would be a good thing.\n\n* ew/svn (Wed Jun 13 02:23:28 2007 -0700) 1 commit\n + git-svn: allow dcommit to retain local merge information\n\nAny negative feedback on this?  Otherwise will merge.\n\n* jo/init (Thu Jun 7 07:50:30 2007 -0500) 2 commits\n + Quiet the output from git-init when cloning, if requested.\n + Add an option to quiet git-init.\n\nOpinions?\n"},{"id":"48883","messageId":"7vtzrosynb.fsf@assigned-by-dhcp.cox.net","threadId":"8139","inReplyTo":"7vd4zb3bid.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-07-28T08:47:20Z","receivedAt":"2007-07-28T08:47:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here are the topics that have been cooking.  Commits prefixed\nwith '-' are only in 'pu' while commits prefixed with '+' are\nin 'next'.  The topics list the commits in reverse chronological\norder.\n\n* bs/lock (Thu Jul 26 22:13:12 2007 -0700) 3 commits\n + Add test for symlinked configuration file updates.\n + use lockfile.c routines in git_commit_set_multivar()\n + fully resolve symlinks when creating lockfiles\n\nI would like to have this in 1.5.3, as it appears to be\nobviously and trivially correct, and resolves real issues we saw\nreported on the list and #git channel.\n\n* js/worktree (Thu Jul 26 07:32:49 2007 +0100) 5 commits\n . With work-trees possibly inside git-dir, be more generous\n . Add test for sanitized work-tree behaviour\n . Clean up work-tree handling\n . Add functions get_relative_cwd() and is_inside_dir()\n . Add is_absolute_path(), make_absolute_path() and normalize_path()\n\nDscho is dead set fixing broken WORK_TREE series that is already\nin 'master'.  The series so far unfortunately has still been\nuntestable state, but the basic approach of cleaning up seems\nsound, and knowing him I am reasonably confident that this will\nbe at least 'next' quality soon enough.\n\n* cr/tag (Mon Jul 23 12:58:27 2007 +0100) 5 commits\n + Teach \"git stripspace\" the --strip-comments option\n + Make verify-tag a builtin.\n + builtin-tag.c: Fix two memory leaks and minor notation changes.\n + launch_editor(): Heed GIT_EDITOR and core.editor settings\n + Make git tag a builtin.\n\nCarlos did a good job at very carefully crafting this series,\nunder Dscho's supervision.  Judging from the quality of the\nseries, I would personally love to have this in 1.5.3.  But as a\nmatter of principle, replacing an implementation with a totally\ndifferent one post -rc is not something I'd want to make a\nprecedent of.  This will be merged early after 1.5.3.\n\n* mc/logsize (Fri Jul 20 20:15:13 2007 +0200) 1 commit\n - Add --log-size to git log to print message size\n\nThis adds a new option --log-size that is to primarily help\nloading \"git log --pretty=raw\" output by qgit.  It is probably\nnot useful with any other combination of options, with \"-p\",\n\"--stat\", \"--pretty={email,oneline}\", etc., as the \"length\nindicator\" is at the wrong place (it should be the first line of\neach record, not on the second line), but it is good enough for\nhelping qgit.  This (or improvement of it if one comes up) will\nmost likely to be in 'master' after 1.5.3.\n\n* js/recursive-fix (Tue Jul 17 18:14:48 2007 +0100) 2 commits\n . Add tests for cherry-pick d/f conflict which should be none\n . merge-recursive: sometimes, d/f conflict is not an issue\n\nThis is to paper over a design bug in merge-recursive d/f\nconflict checking code.  I'd expect we would want to rethink the\nwhole merge datapath after 1.5.3 and prefer to leave this series\nout of 1.5.3.\n\n* jc/blame (Thu Jul 12 10:49:08 2007 -0700) 4 commits\n - git-log --follow?\n - git-blame: optimize get_origin() from linear search to hash-\n   lookup.\n - git-blame: pass \"struct scoreboard *\" pointers around.\n - blame: lift structure definitions up\n\nThe tip of this is Linus's \"follow single file\".  I will\ncherry-pick and put it in 'next' after 1.5.3.\n\n* db/fetch-pack (Tue Jul 10 00:38:42 2007 -0400) 1 commit\n . Make fetch-pack a builtin with an internal API\n\nDaniel has a few more patches in this series we have already\nseen on the list; I'll ask him to rebase/repost after 1.5.3.\n\n* jc/stash-create (Mon Jul 9 00:51:23 2007 -0700) 2 commits\n . rebase: allow starting from a dirty tree.\n . stash: implement \"stash create\"\n\nI did this just for fun, but come to think of it, the user can\nrun git-stash himself when git-rebase complains the working tree\nis dirty anyway, so this may probably not so useful.\n\n* dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit\n . Enhance unpack-objects for live repo and large objects\n\nThis is to deliberately avoid placing large blob to packfile.\nNico had objections on this type of special purpose hacks, and I\nagree with him.\n\n* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits\n - test-para: combined diff between HEAD, index and working tree.\n - para-walk: walk n trees, index and working tree in parallel\n"}]}