{"thread":{"id":"22378","subject":"What's cooking in git.git (Jan 2010, #08; Sun, 24)","startedAt":"2010-01-25T04:39:38Z","lastAt":"2010-01-26T00:59:07Z","messageCount":9,"participants":["Junio C Hamano","Johannes Sixt","Jakub Narebski","Petr Baudis","J.H."],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"132576","messageId":"7vfx5u6bn9.fsf@alter.siamese.dyndns.org","threadId":"22378","inReplyTo":null,"subject":"What's cooking in git.git (Jan 2010, #08; Sun, 24)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-25T04:39:38Z","receivedAt":"2010-01-25T04:39:38Z","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 with '-' are\nonly in 'pu' while commits prefixed with '+' are in 'next'.  The ones\nmarked with '.' do not appear in any of the integration branches, but I am\nstill holding onto them.\n\n--------------------------------------------------\n[Graduated to \"master\"]\n\n* jc/fix-tree-walk (2009-09-14) 7 commits\n  (merged to 'next' on 2010-01-13 at 1c01b87)\n + read-tree --debug-unpack\n + unpack-trees.c: look ahead in the index\n + unpack-trees.c: prepare for looking ahead in the index\n + Aggressive three-way merge: fix D/F case\n + traverse_trees(): handle D/F conflict case sanely\n + more D/F conflict tests\n + tests: move convenience regexp to match object names to test-lib.sh\n\nThis is fix for a tricky codepath; I've been using this personally during\nthe whole cycle up to point, so hopefully it finally have nailed all the\ncorner cases?  Knock wood...\n\n--------------------------------------------------\n[New Topics]\n\n* cc/reset-keep (2010-01-19) 5 commits\n - reset: disallow using --keep when there are unmerged entries\n - reset: disallow \"reset --keep\" outside a work tree\n - Documentation: reset: describe new \"--keep\" option\n - reset: add test cases for \"--keep\" option\n - reset: add option \"--keep\" to \"git reset\"\n\nI do not think I'd ever use this, and I am not convinced I can sell this\nto users as a great new feature without confusing them unnecessarily, but\nperhaps queuing it to pu to give it wider visibility may help somebody\ncoming up with a better way to defend the feature and introduce it to\nusers without confusing them than Christan nor I managed to.\n\n* jc/ce-uptodate (2010-01-24) 1 commit\n - Make ce_uptodate() trustworthy again\n\nI think this and Jens Lehmann's follow-up patch to avoid calling\nis_submodule_modified() are needed before 1.7.0\n\n--------------------------------------------------\n[Cooking]\n\n* jh/notes (2010-01-17) 20 commits\n - builtin-gc: Teach the new --notes option to garbage-collect notes\n - Notes API: gc_notes(): Prune notes that belong to non-existing objects\n - t3305: Verify that removing notes triggers automatic fanout consolidation\n - builtin-notes: Teach -d option for deleting existing notes\n - Teach builtin-notes to remove empty notes\n - Teach notes code to properly preserve non-notes in the notes tree\n - t3305: Verify that adding many notes with git-notes triggers increased fanout\n - t3301: Verify successful annotation of non-commits\n - Builtin-ify git-notes\n - Refactor notes concatenation into a flexible interface for combining notes\n - Notes API: Allow multiple concurrent notes trees with new struct notes_tree\n - Notes API: write_notes_tree(): Store the notes tree in the database\n - Notes API: for_each_note(): Traverse the entire notes tree with a callback\n - Notes API: get_note(): Return the note annotating the given object\n - Notes API: remove_note(): Remove note objects from the notes tree structure\n - Notes API: add_note(): Add note objects to the internal notes tree structure\n - Notes API: init_notes(): Initialize the notes tree from the given notes ref\n - Add tests for checking correct handling of $GIT_NOTES_REF and core.notesRef\n - Notes API: get_commit_notes() -> format_note() + remove the commit restriction\n - Minor non-functional fixes to notes.c\n\nThe changes to test vector this series makes to t3301 breaks tests that\nare in 'master', so 'pu' doesn't pass it.\n\n* jh/gitweb-cached (2010-01-13) 9 commits\n - gitweb: File based caching layer (from git.kernel.org)\n - gitweb: Convert output to using indirect file handle\n - gitweb: cleanup error message produced by undefined $site_header\n - gitweb: add a get function to compliment print_sort_th\n - gitweb: add a get function to compliment print_local_time\n - gitweb: Makefile improvements\n - gitweb: Add option to force version match\n - gitweb: change die_error to take \"extra\" argument for extended die information\n - gitweb: Load checking\n\nI know there is a series to split the later ones into smaller chunks that\nare being discussed on the list, but they don't appear here.  I'd prefer\nto pick the series up after all the dust from the discussion settles.\n\n* jc/grep-author-all-match-implicit (2010-01-17) 1 commit\n - \"log --author=me --grep=it\" should find intersection, not union\n"},{"id":"132616","messageId":"7vsk9u2g3k.fsf@alter.siamese.dyndns.org","threadId":"22378","inReplyTo":"7vfx5u6bn9.fsf@alter.siamese.dyndns.org","subject":"Issues that need to be resolved before 1.7.0-rc1","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-25T18:29:19Z","receivedAt":"2010-01-25T18:29:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Right now 'next' is empty and there are a handful topics in 'pu':\n\n - Jens Lehmann's updates to omit expensive is_submodule_modified() call\n   when running \"diff --ignore-submodules\" and to make \"diff --submodule\"\n   to show the \"dirty worktree\" status.  I think they should be in 1.7.0\n   as part of the series to show work tree/index dirtiness in \"git diff\"\n   output from the superproject.\n\n - Christian Couder's \"reset --keep\".  I am inclined to exclude it from\n   1.7.0 as I cannot make a convincing argument to sell this to users\n   without confusing them (even I am not convinced even though I do fairly\n   straight line development at day-job), but hopefully we can keep\n   cooking it in 'pu/next'.\n\n - Johan Herland's notes updates.  Won't be ready for 1.7.0 but hopefully\n   we can keep cooking in 'pu/next'.\n\n - John Hawley's gitweb caching layer.  Jakub is splitting them into\n   smaller pieces and they are still generating discussions.\n\n - My \"how about this\" patch to make 'grep --author=foo --grep=bar' to\n   implicitly run --all-match; this is not yet readyand needs reworking.\n\nThere also is a discussion on //server/share path on msysgit, that was\nstarted since 288123f (ignore duplicated slashes in make_relative_path(),\n2010-01-21).  If that commit _breaks_ use case on msysgit that used to\nwork, I think the sanest course of action is to revert it and ship 1.7.0\nwith the same breakage we've had forever when the user gives extra slashes\nin the paths to --git-dir or --work-tree options.  We could instead apply\nThomas's patch\n\nMessage-ID: <379d55c6a4110736aadb8ace3b050de879a9deab.1264118830.git.trast@student.ethz.ch>\n\nthat changed behaviour in much narrower case, which should be safer.  In\nany case, a more intrusive change for UNC is outside the scope of 1.7.0\n(discussion and preparation can continue on 'pu/next').\n\nI saw a few patches and discussion to git-p4 in contrib from Pal-Kristian\nEngstad and I understand that we are waiting for revised version before I\nshould take any action on them.\n\nThe above are the current set of unresolved topics and their status but I\nam sure I've missed some others.  Please remind me and the list if there\nare other important ones that need to be discussed.\n"},{"id":"132634","messageId":"201001252217.42501.j6t@kdbg.org","threadId":"22378","inReplyTo":"7vsk9u2g3k.fsf@alter.siamese.dyndns.org","subject":"Re: Issues that need to be resolved before 1.7.0-rc1","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2010-01-25T21:17:42Z","receivedAt":"2010-01-25T21:17:42Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Montag, 25. Januar 2010, Junio C Hamano wrote:\n> There also is a discussion on //server/share path on msysgit, that was\n> started since 288123f (ignore duplicated slashes in make_relative_path(),\n> 2010-01-21).  If that commit _breaks_ use case on msysgit that used to\n> work, I think the sanest course of action is to revert it...\n\nIFAICS, this patch is not a regression w.r.t. //server/share paths.\n\nThe discussion is about that support of //server/share paths in msysgit is \npoor in general. For example, it is not possible to\n\n  git clone //server/share/repo.git\n\nwith different failure modes depending on whether forward slashes or \nbackslashes are used.\n\n-- Hannes\n"},{"id":"132642","messageId":"m3eildbydx.fsf@localhost.localdomain","threadId":"22378","inReplyTo":"7vfx5u6bn9.fsf@alter.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Jan 2010, #08; Sun, 24)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-01-25T22:43:01Z","receivedAt":"2010-01-25T22:43:01Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n\n> * jh/gitweb-cached (2010-01-13) 9 commits\n\n>  - gitweb: File based caching layer (from git.kernel.org)\n>  - gitweb: Convert output to using indirect file handle\n\n>  - gitweb: cleanup error message produced by undefined $site_header\n>  - gitweb: add a get function to compliment print_sort_th\n>  - gitweb: add a get function to compliment print_local_time\n>  - gitweb: Makefile improvements\n>  - gitweb: Add option to force version match\n>  - gitweb: change die_error to take \"extra\" argument for extended die information\n>  - gitweb: Load checking\n> \n> I know there is a series to split the later ones into smaller chunks that\n> are being discussed on the list, but they don't appear here.  I'd prefer\n> to pick the series up after all the dust from the discussion settles.\n\nWell, this series actually consist of two parts: miscellaneous gitweb\nimprovements and actual gitweb output caching.  The first part is more\nor less ready; in particular the following patches are I think ready\nfor inclusion:\n - gitweb: Makefile improvements\n - gitweb: change die_error to take \"extra\" argument for extended die information\n - gitweb: Load checking\n(Although die_error improvements is used by 'force version match',\nwhich is not ready yet).\n\n\nThe following patches needs minimal fixups or extensions.  In\n - gitweb: add a get function to compliment print_sort_th\n - gitweb: add a get function to compliment print_local_time\nIMVHO the new (unused) get_* functions should really be named format_*\nto follow gitweb convention for naming subroutines.  And of course\nthat would probably require accompanying change to the commit message.\n\nThe patch\n - gitweb: cleanup error message produced by undefined $site_header\nsolves its problem... but not fully.  There are other variables\nholding file names that could, in theory, be undefined.  Also the\ncommit message should perhaps mention that is defensive coding against\nerrors in gitweb config file, as in normal situation those variables\nwould be set to empty string, but not undefined.\n\n\nI am not sure about the\n - gitweb: Add option to force version match\npatch.  It is not that useful if the feature is turned off by default;\non the other hand if the feature is turned on by default the error\nmessage needs to be changed... and be a bit more complicated in the\ncase when there are no config files (see my reply in thread).\n\n\nYou are right that actual caching support is in flux.  The discussion\ncontinues: it is very good that we have the voice from Pasky, too.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"132645","messageId":"20100125231241.GA4159@machine.or.cz","threadId":"22378","inReplyTo":"m3eildbydx.fsf@localhost.localdomain","subject":"Re: What's cooking in git.git (Jan 2010, #08; Sun, 24)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2010-01-25T23:12:41Z","receivedAt":"2010-01-25T23:12:41Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Mon, Jan 25, 2010 at 02:43:01PM -0800, Jakub Narebski wrote:\n> You are right that actual caching support is in flux.  The discussion\n> continues: it is very good that we have the voice from Pasky, too.\n\nUnfortunately, I can't give much time to it, or actual contributions.\nI think it would be great to apply at least the miscellanous-changes\npart to (i) move this further (ii) give jh some positive feedback. :)\nThere are ugly minor things, but they can be patched up later. I think\nit's healthier for new gitweb stuff to develop more in-tree, even\nif that means few angry users annoyed about less-than-perfect UI stuff,\nrather than polish the diamond in infinite discussions; worse is better!\nThe only thing we should be worried about is avoiding introducing new\nbad URL interfaces since we should keep backwards compatibility there.\n\nBut Jakub's opinion is definitely much more important, he gives gitweb\nmuch more time than me.\n\nFor the main caching patch, it seems like good idea to take Jakub's\nsplit-up series instead, let's see what is J.H.'s opinion on the series?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nIf you can't see the value in jet powered ants you should turn in\nyour nerd card. -- Dunbal (464142)\n"},{"id":"132647","messageId":"7vfx5t3fxo.fsf@alter.siamese.dyndns.org","threadId":"22378","inReplyTo":"20100125231241.GA4159@machine.or.cz","subject":"Re: What's cooking in git.git (Jan 2010, #08; Sun, 24)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-01-25T23:47:31Z","receivedAt":"2010-01-25T23:47:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis <pasky@suse.cz> writes:\n\n> ... I think\n> it's healthier for new gitweb stuff to develop more in-tree, even\n> if that means few angry users annoyed about less-than-perfect UI stuff,\n> rather than polish the diamond in infinite discussions; worse is better!\n> The only thing we should be worried about is avoiding introducing new\n> bad URL interfaces since we should keep backwards compatibility there.\n> ...\n> For the main caching patch, it seems like good idea to take Jakub's\n> split-up series instead, let's see what is J.H.'s opinion on the series?\n\nSounds reasonable.\n"},{"id":"132649","messageId":"201001260107.25796.jnareb@gmail.com","threadId":"22378","inReplyTo":"20100125231241.GA4159@machine.or.cz","subject":"Re: What's cooking in git.git (Jan 2010, #08; Sun, 24)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-01-26T00:07:24Z","receivedAt":"2010-01-26T00:07:24Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Tue, Jan 26, 2010 at 00:12 +0100, Petr Baudis wrote:\n> On Mon, Jan 25, 2010 at 02:43:01PM -0800, Jakub Narebski wrote:\n\n> > You are right that actual caching support is in flux.  The discussion\n> > continues: it is very good that we have the voice from Pasky, too.\n> \n> Unfortunately, I can't give much time to it, or actual contributions.\n> I think it would be great to apply at least the miscellanous-changes\n> part to (i) move this further (ii) give jh some positive feedback. :)\n> There are ugly minor things, but they can be patched up later. I think\n> it's healthier for new gitweb stuff to develop more in-tree, even\n> if that means few angry users annoyed about less-than-perfect UI stuff,\n> rather than polish the diamond in infinite discussions; worse is better!\n> The only thing we should be worried about is avoiding introducing new\n> bad URL interfaces since we should keep backwards compatibility there.\n\nI think that while some patches from the miscellaneous-changes part are\ngood now (and very nice to have, especially load checking and \ngitweb/Makefile), there needs to be one last, final reroll of those\npatches.\n\nI am waiting for response from (I guess busy) J.H.; I can do the re-roll\nif he is too busy to work on it.\n\n> For the main caching patch, it seems like good idea to take Jakub's\n> split-up series instead, let's see what is J.H.'s opinion on the series?\n\nLet me at least make them into proper patches, with commit messages and \nconfigureability at least of the original caching patch by J.H.\n\nAlso the question whether to create 'print -> print $out' patch, or to\nmanipulate *STDOUT instead must be solved, I think, before applying\nthose patches... well, at least beyond 'pu'.\n\nI am waiting for promised J.H. comments, when he will have time for it...\n-- \nJakub Narebski\nPoland\n"},{"id":"132650","messageId":"4B5E357A.50607@kernel.org","threadId":"22378","inReplyTo":"201001260107.25796.jnareb@gmail.com","subject":"Re: What's cooking in git.git (Jan 2010, #08; Sun, 24)","fromName":"J.H.","fromEmail":"warthog9@kernel.org","sentAt":"2010-01-26T00:21:14Z","receivedAt":"2010-01-26T00:21:14Z","isPatch":false,"sender":{"key":"warthog9@kernel.org","avatar":"https://avatars.githubusercontent.com/u/2334704?v=4"},"body":"\n>\n> I am waiting for response from (I guess busy) J.H.; I can do the re-roll\n> if he is too busy to work on it.\n>\n>   \n\nI'm juggling about 4 things in the air right now, with gitweb being one \nof them, and two of them involving external entities to kernel.org.  \nIt's good news all told, just requires a fair amount of my time \n(currently) and babysitting.  I've been digging through the patches \nyou've got right now.  I should really just pull them in from your git \ntree again.\n\nAfter reading through some of the discussions today I've had some more \nideas on the caching stuff, they are written up on my whiteboard and I \nmight be able to get to shortly, but I've got a rather large wall \nlooming ahead of me that's going to chew up a *LOT* (read at least a \nmonth, if not two) of my time, so I'm a bit under the gun to try and get \nthis as far as I can before I hit that wall or this is going to fall by \nthe wayside again till I've got time again.\n\n>> For the main caching patch, it seems like good idea to take Jakub's\n>> split-up series instead, let's see what is J.H.'s opinion on the series?\n>>     \n>\n> Let me at least make them into proper patches, with commit messages and \n> configureability at least of the original caching patch by J.H.\n>\n> Also the question whether to create 'print -> print $out' patch, or to\n> manipulate *STDOUT instead must be solved, I think, before applying\n> those patches... well, at least beyond 'pu'.\n>\n> I am waiting for promised J.H. comments, when he will have time for it...\n>   \n"},{"id":"132655","messageId":"201001260159.09286.jnareb@gmail.com","threadId":"22378","inReplyTo":"4B5E357A.50607@kernel.org","subject":"Re: What's cooking in git.git (Jan 2010, #08; Sun, 24)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-01-26T00:59:07Z","receivedAt":"2010-01-26T00:59:07Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 25 Jan 2010 at 16:21:51 -0800 (PST), J.H. wrote:\n> >\n> > I am waiting for response from (I guess busy) J.H.; I can do the re-roll\n> > if he is too busy to work on it.\n> \n> I'm juggling about 4 things in the air right now, with gitweb being one \n> of them, and two of them involving external entities to kernel.org.  \n> It's good news all told, just requires a fair amount of my time \n> (currently) and babysitting.  I've been digging through the patches \n> you've got right now.  I should really just pull them in from your git \n> tree again.\n\nNote however that my series (gitweb/cache-kernel branch) is based on\ngitweb-ml-v2, not on newer gitweb-ml-v5.\n\n> After reading through some of the discussions today I've had some more \n> ideas on the caching stuff, they are written up on my whiteboard and I \n> might be able to get to shortly, but I've got a rather large wall \n> looming ahead of me that's going to chew up a *LOT* (read at least a \n> month, if not two) of my time, so I'm a bit under the gun to try and get \n> this as far as I can before I hit that wall or this is going to fall by \n> the wayside again till I've got time again.\n\nI think the best way of utilizing your time would be for you to take\nactive part in discussion, especially in what git.kernel.org needs and why.\n\nI can clean up the miscellaneous improvements parts myself, and re-roll\ncaching patches.\n\n> > > For the main caching patch, it seems like good idea to take Jakub's\n> > > split-up series instead, let's see what is J.H.'s opinion on the series?\n> > >     \n> >\n> > Let me at least make them into proper patches, with commit messages and \n> > configureability at least of the original caching patch by J.H.\n> >\n> > Also the question whether to create 'print -> print $out' patch, or to\n> > manipulate *STDOUT instead must be solved, I think, before applying\n> > those patches... well, at least beyond 'pu'.\n> >\n> > I am waiting for promised J.H. comments, when he will have time for it...\n\n-- \nJakub Narebski\nPoland\n"}]}