{"thread":{"id":"16819","subject":"What's cooking in git.git (Dec 2008, #03; Sun, 21)","startedAt":"2008-12-21T12:23:22Z","lastAt":"2008-12-24T11:55:10Z","messageCount":8,"participants":["Junio C Hamano","Jakub Narebski","Jeff King","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"98488","messageId":"7vr641pvid.fsf@gitster.siamese.dyndns.org","threadId":"16819","inReplyTo":null,"subject":"What's cooking in git.git (Dec 2008, #03; Sun, 21)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-21T12:23:22Z","receivedAt":"2008-12-21T12:23:22Z","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 ones marked with '.' do not appear in any of the branches,\nbut I am still holding onto them.\n\nThe topics list the commits in reverse chronological order.  The topics\nmeant to be merged to the maintenance series have \"maint-\" in their names.\n\nAs we have already passed -rc3, things queued in 'next' let alone 'pu' are\nunlikely to be merged to 'master' by the end of year unless otherwise\nnoted.\n\n----------------------------------------------------------------\n[New Topics]\n\n* mk/gitweb-feature (Mon Dec 15 22:16:19 2008 -0800) 1 commit\n - gitweb: unify boolean feature subroutines\n\n* cb/merge-recursive-fix (Mon Dec 15 02:41:24 2008 -0800) 3 commits\n - Merge branch 'cb/maint-merge-recursive-fix' into cb/merge-\n   recursive-fix\n - merge-recursive: do not clobber untracked working tree garbage\n - modify/delete conflict resolution overwrites untracked file\n\n* cb/maint-merge-recursive-fix (Sun Dec 14 19:40:09 2008 -0800) 2 commits\n - merge-recursive: do not clobber untracked working tree garbage\n - modify/delete conflict resolution overwrites untracked file\n\n* js/notes (Sat Dec 20 13:06:03 2008 +0100) 4 commits\n - Add an expensive test for git-notes\n - Speed up git notes lookup\n - Add a script to edit/inspect notes\n - Introduce commit notes\n\n* js/rebase-i-p (Mon Dec 15 11:05:31 2008 +0100) 2 commits\n - rebase -i -p: Fix --continue after a merge could not be redone\n - Show a failure of rebase -p if the merge had a conflict\n\nI am undecided whether I should include these in 1.6.1 and have been\nwaiting for comments from Dscho.\n\n----------------------------------------------------------------\n[Post 1.6.1 items]\n\n* wp/add-p-goto (Thu Dec 4 10:22:40 2008 +0000) 2 commits\n + Add 'g' command to go to a hunk\n + Add subroutine to display one-line summary of hunks\n\n* jn/gitweb-blame (Thu Dec 11 01:33:29 2008 +0100) 3 commits\n - gitweb: cache $parent_commit info in git_blame()\n - gitweb: A bit of code cleanup in git_blame()\n - gitweb: Move 'lineno' id from link to row element in git_blame\n\nI've briefly looked at the resurrection of Ajaxy blame that comes on top\nof this series and it looked promising.\n\n* mv/um-pdf (Wed Dec 10 23:44:50 2008 +0100) 1 commit\n - Add support for a pdf version of the user manual\n\nI do not have a new enough combination of dblatex and asciidoc myself but\nthis may help interested people.\n\n* np/auto-thread (Mon Dec 15 20:44:30 2008 +0100) 3 commits\n + Force t5302 to use a single thread\n + pack-objects: don't use too many threads with few objects\n + autodetect number of CPUs by default when using threads\n\n* sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits\n - gitweb: Optional grouping of projects by category\n - gitweb: Split git_project_list_body in two functions\n - gitweb: Modularized git_get_project_description to be more generic\n\n* gb/gitweb-patch (Thu Dec 18 08:13:19 2008 +0100) 4 commits\n - gitweb: link to patch(es) view in commit(diff) and (short)log view\n - gitweb: add patches view\n - gitweb: change call pattern for git_commitdiff\n - gitweb: add patch view\n\nUpdated series.\n\n* lt/reset-merge (Wed Dec 3 18:00:12 2008 -0800) 2 commits\n + Document \"git-reset --merge\"\n + Add 'merge' mode to 'git reset'\n\n* wp/add-patch-find (Thu Nov 27 04:08:03 2008 +0000) 3 commits\n . In add --patch, Handle K,k,J,j slightly more gracefully.\n . Add / command in add --patch\n . git-add -i/-p: Change prompt separater from slash to comma\n\nI am still holding onto this earlier topic to add '/' subcommand to allow\nfinding a hunk with given text, but I'd rather not merge/rebase it on top\nof wp/add-p-goto series myself.  Waiting for a reroll.\n\n* cb/mergetool (Fri Dec 12 21:48:41 2008 +0000) 4 commits\n - mergetool: Don't keep temporary merge files unless told to\n - mergetool: Add prompt to continue after failing to merge a file\n - Add -y/--no-prompt option to mergetool\n - Fix some tab/space inconsistencies in git-mergetool.sh\n\nUpdated series.  Waiting for comments from the original author (Ted) and\nother interested parties.\n\n----------------------------------------------------------------\n[Graduated to \"master\"]\n\nNothing cooking was \"not so trivial but want to have in final\".\n\n----------------------------------------------------------------\n[Will merge to \"master\" soon]\n\nWhat are you looking for?  We are in -rc ;-)\n\n----------------------------------------------------------------\n[On Hold]\n\n* kb/am-directory (Fri Aug 29 15:27:50 2008 -0700) 1 commit\n . git-am: Pass the --directory option through to git-apply\n\nA reroll of this by Simon Schubert triggered a series to fix a parameter\npropagation bug, and another reroll to add \"git am --directory=path/\"\nshould be much easier now.  I am not likely to use the feature myself, so\nit is up to intrested volunteers to carry it forward.\n\n* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits\n + blame: show \"previous\" information in --porcelain/--incremental\n   format\n + git-blame: refactor code to emit \"porcelain format\" output\n\n* ds/uintmax-config (Mon Nov 3 09:14:28 2008 -0900) 1 commit\n - autoconf: Enable threaded delta search when pthreads are supported\n\nRebased to 'master', that introduced NO_PTHREADS.\n\n* cc/bisect-replace (Mon Nov 24 22:20:30 2008 +0100) 9 commits\n - bisect: add \"--no-replace\" option to bisect without using replace\n   refs\n - rev-list: make it possible to disable replacing using \"--no-\n   bisect-replace\"\n - bisect: use \"--bisect-replace\" options when checking merge bases\n - merge-base: add \"--bisect-replace\" option to use fixed up revs\n - commit: add \"bisect_replace_all\" prototype to \"commit.h\"\n - rev-list: add \"--bisect-replace\" to list revisions with fixed up\n   history\n - Documentation: add \"git bisect replace\" documentation\n - bisect: add test cases for \"git bisect replace\"\n - bisect: add \"git bisect replace\" subcommand\n\nI really hate the idea of introducing a potentially much more useful\nreplacement of the existing graft mechanism and tie it very tightly to\nbisect, making it unusable from outside.\n\n (1) I do not think \"bisect replace\" workflow is a practical and usable\n     one;\n\n (2) The underlying mechanism to express \"this object replaces that other\n     object\" is much easier to work with than what the graft does which is\n     \"the parents of this commit are these\", and idea to use the normal\n     ref to point at them means this can potentially be used for\n     transferring the graft information across repositories, which the\n     current graft mechanism cannot do.\n\n (3) Because I like the aspect (2) of this series so much, it deeply\n     disappoints and troubles me that this is implemented minimally near\n     the surface, and that it is controlled by the \"bisect\" Porcelain\n     alone, by explicitly passing command line arguments.\n\nI think a mechanism like this should be added to replace grafts, but it\nshould always be enabled for normal revision traversal operation, while\nalways disabled for object enumeration and transfer operation (iow, fsck,\nfetch and push should use the real ancestry information recorded in the\nunderlying objects, while rev-list, log, etc. should always use the\nreplaced objects).  I have a suspicion that even cat-file could honor it.\n\n* nd/narrow (Sun Nov 30 17:54:38 2008 +0700) 17 commits\n - wt-status: show sparse checkout info\n - Introduce default sparse patterns (core.defaultsparse)\n - checkout: add new options to support sparse checkout\n - clone: support sparse checkout with --sparse-checkout option\n - unpack_trees(): add support for sparse checkout\n - unpack_trees(): keep track of unmerged entries\n - Introduce \"sparse patterns\"\n - Merge branch 'master' into nd/narrow\n + t2104: touch portability fix\n + grep: skip files outside sparse checkout area\n + checkout_entry(): CE_NO_CHECKOUT on checked out entries.\n + Prevent diff machinery from examining worktree outside sparse\n   checkout\n + ls-files: Add tests for --sparse and friends\n + update-index: add --checkout/--no-checkout to update\n   CE_NO_CHECKOUT bit\n + update-index: refactor mark_valid() in preparation for new options\n + ls-files: add options to support sparse checkout\n + Introduce CE_NO_CHECKOUT bit\n\nKicked back to 'on hold' until 1.6.1 final by popular demand; will be\ndropped from 'next' (see recent discussion on the interaction between the\ncheckout area and commands such as \"grep\").\n\n* jc/clone-symref-2 (Sat Nov 29 23:38:21 2008 -0800) 7 commits\n - clone: test the new HEAD detection logic\n - Merge commit 'HEAD@{2}' into HEAD\n - upload-pack: send the HEAD information\n - clone: find the current branch more explicitly\n - connect.c::read_extra_info(): find where HEAD points at\n - connect.c::read_extra_info(): prepare to receive more than server\n   capabilities\n - get_remote_heads(): refactor code to read \"server capabilities\"\n\nThis is no way meant for 1.6.1, let alone next, yet.\n\n* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit\n - \"git push\": tellme-more protocol extension\n\nThis seems to have a deadlock during communication between the peers.\nSomeone needs to pick up this topic and resolve the deadlock before it can\ncontinue.\n\n* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit\n - diff: enable \"too large a rename\" warning when -M/-C is explicitly\n   asked for\n\nThis would be the right thing to do for command line use,\nbut gitk will be hit due to tcl/tk's limitation, so I am holding\nthis back for now.\n\n* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits\n - git-am --forge: add Signed-off-by: line for the author\n - git-am: clean-up Signed-off-by: lines\n - stripspace: add --log-clean option to clean up signed-off-by:\n   lines\n - stripspace: use parse_options()\n - Add \"git am -s\" test\n - git-am: refactor code to add signed-off-by line for the committer\n\n* jc/post-simplify (Fri Aug 15 01:34:51 2008 -0700) 2 commits\n . revision --simplify-merges: incremental simplification\n . revision --simplify-merges: prepare for incremental simplification\n\n* jc/clone-symref (Sat Nov 29 23:38:21 2008 -0800) 6 commits\n . clone: test the new HEAD detection logic\n . Merge sender side of \"symbolic-ref\" protocol extension\n . upload-pack: implement protocol extension \"symbolic-ref\"\n . clone: find the current branch more explicitly\n . get_remote_heads(): do not assume that the operation is one-way\n . upload-pack.c: refactor receive_needs()\n\n* jk/valgrind (Thu Oct 23 04:30:45 2008 +0000) 2 commits\n . valgrind: ignore ldso errors\n . add valgrind support in test scripts\n\n* jc/apply (Sun Sep 7 14:36:24 2008 -0700) 1 commit\n . WIP\n"},{"id":"98496","messageId":"m363ldcpv9.fsf@localhost.localdomain","threadId":"16819","inReplyTo":"7vr641pvid.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Dec 2008, #03; Sun, 21)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-12-21T19:03:42Z","receivedAt":"2008-12-21T19:03:42Z","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> [New Topics]\n> \n> * mk/gitweb-feature (Mon Dec 15 22:16:19 2008 -0800) 1 commit\n>  - gitweb: unify boolean feature subroutines\n\nThe last version, I assume? IMHO it is a good change.\n \n> * js/notes (Sat Dec 20 13:06:03 2008 +0100) 4 commits\n>  - Add an expensive test for git-notes\n>  - Speed up git notes lookup\n>  - Add a script to edit/inspect notes\n>  - Introduce commit notes\n\nNice to see it resurrected.\n \n> * jn/gitweb-blame (Thu Dec 11 01:33:29 2008 +0100) 3 commits\n>  - gitweb: cache $parent_commit info in git_blame()\n>  - gitweb: A bit of code cleanup in git_blame()\n>  - gitweb: Move 'lineno' id from link to row element in git_blame\n> \n> I've briefly looked at the resurrection of Ajaxy blame that comes on top\n> of this series and it looked promising.\n\nThere are a few issues to test and to resolve with Ajaxy blame\n(blame_incremental):\n * does it work correctly with browsers other than Mozilla 1.17.2\n   and Konqueror 3.5.3?\n * what gives better performance, and better visible performance\n   on the client side: onreadystatechange or setInterval (and what\n   interval)?\n * is it better to do more work on the server side, and for example\n   send JSON with ready commits data; it is better to enable autoflush\n   if sending raw \"git blame --incremental\" output?\n * the 'how long it took to generate page' patch should be decoupled,\n   improved, and send separately...\n \n> * sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits\n>  - gitweb: Optional grouping of projects by category\n>  - gitweb: Split git_project_list_body in two functions\n>  - gitweb: Modularized git_get_project_description to be more generic\n\nI think it is not yet finished, but it looks nice.\n \n> * gb/gitweb-patch (Thu Dec 18 08:13:19 2008 +0100) 4 commits\n>  - gitweb: link to patch(es) view in commit(diff) and (short)log view\n>  - gitweb: add patches view\n>  - gitweb: change call pattern for git_commitdiff\n>  - gitweb: add patch view\n> \n> Updated series.\n\nI'd have to review resend series, but I think it would get Ack from\nme.\n\n> * cc/bisect-replace (Mon Nov 24 22:20:30 2008 +0100) 9 commits\n> * nd/narrow (Sun Nov 30 17:54:38 2008 +0700) 17 commits\n> * jc/clone-symref-2 (Sat Nov 29 23:38:21 2008 -0800) 7 commits\n> * jc/clone-symref (Sat Nov 29 23:38:21 2008 -0800) 6 commits\n\nThose are interesting...\n\n> * jc/apply (Sun Sep 7 14:36:24 2008 -0700) 1 commit\n>  . WIP\n\nUh?\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"98600","messageId":"20081223120534.GA21633@coredump.intra.peff.net","threadId":"16819","inReplyTo":"7vr641pvid.fsf@gitster.siamese.dyndns.org","subject":"Re: What's cooking in git.git (Dec 2008, #03; Sun, 21)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-12-23T12:05:35Z","receivedAt":"2008-12-23T12:05:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Dec 21, 2008 at 04:23:22AM -0800, Junio C Hamano wrote:\n\n> * js/notes (Sat Dec 20 13:06:03 2008 +0100) 4 commits\n>  - Add an expensive test for git-notes\n>  - Speed up git notes lookup\n>  - Add a script to edit/inspect notes\n>  - Introduce commit notes\n\nI haven't had much time to really look at this closely, and I probably\nwon't for another week or so due to the holidays. But from my cursory\nexamination, I think I want to propose something that is a bit\ndifferent. So if nobody objects (and I think Dscho already said he was\ngoing to be out of touch for two weeks due to the holidays) I'd like\nthis to remain in pu for the time being.\n\n-Peff\n"},{"id":"98620","messageId":"alpine.DEB.1.00.0812231725270.30769@pacific.mpi-cbg.de","threadId":"16819","inReplyTo":"20081223120534.GA21633@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Dec 2008, #03; Sun, 21)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-12-23T16:26:01Z","receivedAt":"2008-12-23T16:26:01Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 23 Dec 2008, Jeff King wrote:\n\n> On Sun, Dec 21, 2008 at 04:23:22AM -0800, Junio C Hamano wrote:\n> \n> > * js/notes (Sat Dec 20 13:06:03 2008 +0100) 4 commits\n> >  - Add an expensive test for git-notes\n> >  - Speed up git notes lookup\n> >  - Add a script to edit/inspect notes\n> >  - Introduce commit notes\n> \n> I haven't had much time to really look at this closely, and I probably \n> won't for another week or so due to the holidays. But from my cursory \n> examination, I think I want to propose something that is a bit \n> different.\n\nCould you be a bit more, like, specific, please?\n\nCiao,\nDscho\n"},{"id":"98621","messageId":"20081223163811.GA25658@coredump.intra.peff.net","threadId":"16819","inReplyTo":"alpine.DEB.1.00.0812231725270.30769@pacific.mpi-cbg.de","subject":"Re: What's cooking in git.git (Dec 2008, #03; Sun, 21)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-12-23T16:38:13Z","receivedAt":"2008-12-23T16:38:13Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 23, 2008 at 05:26:01PM +0100, Johannes Schindelin wrote:\n\n> > I haven't had much time to really look at this closely, and I probably \n> > won't for another week or so due to the holidays. But from my cursory \n> > examination, I think I want to propose something that is a bit \n> > different.\n> \n> Could you be a bit more, like, specific, please?\n\nThe way that GIT_NOTES_REF and core.notesref work aren't what I had in\nmind. I imagined something more amenable to having lots of different\nmetadata notes.  Refer to the other messages I have written on \"naming\".\n\nI don't want to hold up progress, so if people want those patches in\n\"next\", then go for it. What I really meant by my email was that I think\nmy suggested changes might be simpler to see as a re-roll rather than\npatches on top, but since I can't work on them for a while, I didn't\nwant Junio to take silence as \"OK, nobody has complained, so it's time\nfor this to graduate to next.\" But again, if people are ready to start\nplaying with this and building on top of it, then I don't want to stand\nin the way.\n\n-Peff\n"},{"id":"98622","messageId":"alpine.DEB.1.00.0812231746250.30769@pacific.mpi-cbg.de","threadId":"16819","inReplyTo":"20081223163811.GA25658@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Dec 2008, #03; Sun, 21)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-12-23T16:52:54Z","receivedAt":"2008-12-23T16:52:54Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 23 Dec 2008, Jeff King wrote:\n\n> On Tue, Dec 23, 2008 at 05:26:01PM +0100, Johannes Schindelin wrote:\n> \n> > > I haven't had much time to really look at this closely, and I probably \n> > > won't for another week or so due to the holidays. But from my cursory \n> > > examination, I think I want to propose something that is a bit \n> > > different.\n> > \n> > Could you be a bit more, like, specific, please?\n> \n> The way that GIT_NOTES_REF and core.notesref work aren't what I had in \n> mind. I imagined something more amenable to having lots of different \n> metadata notes.  Refer to the other messages I have written on \"naming\".\n\nUnfortunately, there were way too many messages between you and Govind, \nwith not enough new stuff that could interest me, so I had to stop reading \nthem to avoid depleting my Git time budget each and every single day.\n\nHowever, note that without something like core.notesref you will never be \nable to have private and public notes.\n\nAnd I very much want to have private notes _and_ public notes on the very \nsame commits of the very same branches.\n\n> I don't want to hold up progress, so if people want those patches in \n> \"next\", then go for it. What I really meant by my email was that I think \n> my suggested changes might be simpler to see as a re-roll rather than \n> patches on top, but since I can't work on them for a while, I didn't \n> want Junio to take silence as \"OK, nobody has complained, so it's time \n> for this to graduate to next.\" But again, if people are ready to start \n> playing with this and building on top of it, then I don't want to stand \n> in the way.\n\nI just wanted to fiddle a little bit with profiling, as I really do not \nunderstand why the new notes perform that badly against the old notes, \neven allowing for reading a complete, possibly huge tree into a hashmap.\n\nAnd while I am almost sure that there is a stupid bug lurking that will \nkick the performance again, I think the basic design is sound, and it \nshould be easy to modify no matter which way you want to change the \nbehavior with regards to trees/blobs or refs.\n\nOf course, I'd like Miklos' read-tree bug solved before any more work is \ndone on notes, since we are in -rc4 after all, and that is a potentially \npretty serious bug.\n\nCiao,\nDscho\n"},{"id":"98625","messageId":"20081223173438.GA25699@coredump.intra.peff.net","threadId":"16819","inReplyTo":"alpine.DEB.1.00.0812231746250.30769@pacific.mpi-cbg.de","subject":"Re: What's cooking in git.git (Dec 2008, #03; Sun, 21)","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-12-23T17:34:40Z","receivedAt":"2008-12-23T17:34:40Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 23, 2008 at 05:52:54PM +0100, Johannes Schindelin wrote:\n\n> However, note that without something like core.notesref you will never be \n> able to have private and public notes.\n> \n> And I very much want to have private notes _and_ public notes on the very \n> same commits of the very same branches.\n\nRight. I think core.notesref doesn't go far enough, because it doesn't\nprovide a way to talk about notes from two sources at the same time.\nLike:\n\n  git log --pretty=format:'%N(my-private-notes:foo) %N(public-notes:bar)'\n\n> I just wanted to fiddle a little bit with profiling, as I really do not \n> understand why the new notes perform that badly against the old notes, \n> even allowing for reading a complete, possibly huge tree into a hashmap.\n\nI haven't looked closely at the latest series yet, so I can't comment.\n\n> And while I am almost sure that there is a stupid bug lurking that will \n> kick the performance again, I think the basic design is sound, and it \n> should be easy to modify no matter which way you want to change the \n> behavior with regards to trees/blobs or refs.\n\nI agree that the data structure is sound, so I can probably work on top\nof what you posted, too. I was planning on doing git-notes in C, though.\n\n-Peff\n"},{"id":"98648","messageId":"alpine.DEB.1.00.0812241252080.30769@pacific.mpi-cbg.de","threadId":"16819","inReplyTo":"20081223173438.GA25699@coredump.intra.peff.net","subject":"Re: What's cooking in git.git (Dec 2008, #03; Sun, 21)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-12-24T11:55:10Z","receivedAt":"2008-12-24T11:55:10Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 23 Dec 2008, Jeff King wrote:\n\n> On Tue, Dec 23, 2008 at 05:52:54PM +0100, Johannes Schindelin wrote:\n> \n> > However, note that without something like core.notesref you will never \n> > be able to have private and public notes.\n> > \n> > And I very much want to have private notes _and_ public notes on the \n> > very same commits of the very same branches.\n> \n> Right. I think core.notesref doesn't go far enough, because it doesn't\n> provide a way to talk about notes from two sources at the same time.\n> Like:\n> \n>   git log --pretty=format:'%N(my-private-notes:foo) %N(public-notes:bar)'\n\nAh.  That should be easy to do incrementally, by adding a ref_name \nparameter to the functions in notes.h, which can be NULL (falling back to \nthe default ref).\n\n> > And while I am almost sure that there is a stupid bug lurking that \n> > will kick the performance again, I think the basic design is sound, \n> > and it should be easy to modify no matter which way you want to change \n> > the behavior with regards to trees/blobs or refs.\n> \n> I agree that the data structure is sound, so I can probably work on top\n> of what you posted, too. I was planning on doing git-notes in C, though.\n\nSure.  git-notes.sh is only in shell script to provide a proof-of-concept, \nand an example how to have an ultra-narrow \"checkout\" of the notes ref's \ntree.\n\nCiao,\nDscho\n"}]}