{"thread":{"id":"3581","subject":"What's in git.git","startedAt":"2006-03-06T07:13:20Z","lastAt":"2006-03-13T05:01:06Z","messageCount":9,"participants":["Junio C Hamano","Martin Langhoff","Johannes Schindelin","Lukas Sandström","Fredrik Kuivinen"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"17243","messageId":"7v1wxg82r3.fsf@assigned-by-dhcp.cox.net","threadId":"3581","inReplyTo":null,"subject":"What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-06T07:13:20Z","receivedAt":"2006-03-06T07:13:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The \"deathmatch\" between Ryan's annotate and Fredrik's blame is\nofficially on. Currently the last test in all three branches\nfail. Please do not get alarmed.\n\nI'd like asciidoc tweaks in \"next\" by Francis Daly tested by\npeople who have access to different vintages of docbook-xsl by\ntrying to build manpages. Look for displayed examples, such as\nthe one in git-branch documentation. I've tried it with v1.68\nand getting far better results than before, and Francis says\nv1.69 works fine with or without the change. IOW this is a\nworkaround for a problem in v1.68.\n\nI've been tweaking on-and-off the similarity estimator in the\n\"next\" branch. It has become independent from the xdelta code\nused for pack generation. It may detect more renames that it\nmissed before, and it may miss some other renames and copies.\nIn general, it seems that the algorithm tends to detect slightly\nmore breaks than before. I'd appreciate feedback from people\ninterested in this area.\n\nAnother thing I have started in \"pu\" branch is to stop placing\nan object we decided to delta that is already max-depth deep\nback in the delta-base window, because such a thing only wastes\nthe delta base slot. The changed pack-objects does pick up more\ndelta, but the resulting pack seems bigger and I am puzzled why.\n\nThis may suggest that our criteria to delta should be tightened\na bit (the value of max_size in try_delta should be decreased).\nWe are better off storing a plain deflated representation instad\nof generating a bad, bigger delta. Insights?\n\n-- -- --\n\n* The 'master' branch has these since the last announcement.\n\n- Documentation fixes (Dmitry V. Levin, Mark Wooding, Martin\n Langhoff, Jeff Muizelaar)\n\n git/Documentation: fix SYNOPSIS style bugs\n Documentation/Makefile: Some `git-*.txt' files aren't manpages.\n cvsserver: updated documentation\n cosmetics: change from 'See-Also' to 'See Also'\n documentation: add 'see also' sections to git-rm and git-add\n\n- The deathmatch between annotate/blame (Ryan Anderson, Fredrik\n Kuivinen, me cheerleading)\n\n annotate: Support annotation of files on other revisions.\n git-blame: Make the output human readable\n git-blame: Use the same tests for git-blame as for git-annotate\n blame: avoid -lm by not using log().\n blame and annotate: show localtime with timezone.\n blame: avoid \"diff -u0\".\n annotate/blame tests updates.\n annotate-blame test: don't \"source\", but say \".\"\n annotate-blame test: add evil merge.\n\n- Tweak rev-list (Linus Torvalds)\n\n get_revision(): do not dig deeper when we know we are at the end.\n\n- Fix git-commit --amend (me)\n\n git-commit --amend: allow empty commit.\n\n- Misc fixes and cleanups (Mark Wooding and me)\n\n gitignore: Ignore some more boring things.\n contrib/emacs/Makefile: Provide tool for byte-compiling files.\n Const tightening.\n\n* The 'next' branch, in addition, has these.\n\n- Fix manpage formatting (Francis Daly)\n\n Tweak asciidoc output to work with broken docbook-xsl\n\n- Tweak break/rename/copy similarity estimator tweaks (me)\n\n diffcore-rename: similarity estimator fix.\n count-delta: no need for this anymore.\n diffcore-break: similarity estimator fix.\n diffcore-delta: make change counter to byte oriented again.\n\n- Help pack generation tweaks (me)\n\n verify-pack -v: show delta-chain histogram.\n\n- checkout-index --temp (Shawn Pearce)\n\n Add --temp and --stage=all options to checkout-index.\n\n* The 'pu' branch, in addition, has these.\n\n- WIP: pack generation tweak (me)\n\n [WIP] do not waste delta window with objects with already at max-depth.\n"},{"id":"17245","messageId":"7vr75g6jxu.fsf@assigned-by-dhcp.cox.net","threadId":"3581","inReplyTo":"7v1wxg82r3.fsf@assigned-by-dhcp.cox.net","subject":"[PATCH] blame: unbreak \"diff -U 0\".","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-06T08:45:01Z","receivedAt":"2006-03-06T08:45:01Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> The \"deathmatch\" between Ryan's annotate and Fredrik's blame is\n> officially on. Currently the last test in all three branches\n> fail. Please do not get alarmed.\n\nIt turns out the breakage was caused after merging Fredrik's\nimprovements. I'm double-checking the fix and will be pushing\nout corrected \"master\", \"next\" and \"pu\" shortly.\n\nSorry, Fredrik.\n\n-- >8 --\nSubject: [PATCH] blame: unbreak \"diff -U 0\".\n\nThe commit 604c86d15bb319a1e93ba218fca48ce1c500ae52 changed the\noriginal \"diff -u0\" to \"diff -u -U 0\" for portability.\n\nA big mistake without proper testing.\n\nThe form \"diff -u -U 0\" shows the default 3-line contexts,\nbecause -u and -U 0 contradicts with each other; \"diff -U 0\" (or\nits longhand \"diff --unified=0\") is what we meant.\n\nSigned-off-by: Junio C Hamano \n\n---\n\n blame.c | 4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\n690e307f54b4aa84349b89e8552b25e7495f1cd6\ndiff --git a/blame.c b/blame.c\nindex fca22f9..90338af 100644\n--- a/blame.c\n+++ b/blame.c\n@@ -92,7 +92,7 @@ static struct patch *get_patch(struct co\n \t\tdie(\"write failed: %s\", strerror(errno));\n \tclose(fd);\n \n-\tsprintf(diff_cmd, \"diff -u -U 0 %s %s\", tmp_path1, tmp_path2);\n+\tsprintf(diff_cmd, \"diff -U 0 %s %s\", tmp_path1, tmp_path2);\n \tfin = popen(diff_cmd, \"r\");\n \tif (!fin)\n \t\tdie(\"popen failed: %s\", strerror(errno));\n@@ -234,7 +234,7 @@ static void print_patch(struct patch *p)\n \t}\n }\n \n-#if 0\n+#if DEBUG\n /* For debugging only */\n static void print_map(struct commit *cmit, struct commit *other)\n {\n-- \n1.2.4.g3bcd\n"},{"id":"17246","messageId":"46a038f90603060105m29595745ke64d4a623506c0b0@mail.gmail.com","threadId":"3581","inReplyTo":"7v1wxg82r3.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-03-06T09:05:41Z","receivedAt":"2006-03-06T09:05:41Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 3/6/06, Junio C Hamano wrote:\n> - The deathmatch between annotate/blame (Ryan Anderson, Fredrik\n> Kuivinen, me cheerleading)\n\nAdd fuel to the fire ;-) Can git-blame take cached git-rev-list\noutput like annotate does with -S?\n\n\nm\n"},{"id":"17247","messageId":"Pine.LNX.4.63.0603061012120.1422@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3581","inReplyTo":"7v1wxg82r3.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-03-06T09:15:36Z","receivedAt":"2006-03-06T09:15:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 5 Mar 2006, Junio C Hamano wrote:\n\n> Another thing I have started in \"pu\" branch is to stop placing\n> an object we decided to delta that is already max-depth deep\n> back in the delta-base window, because such a thing only wastes\n> the delta base slot. The changed pack-objects does pick up more\n> delta, but the resulting pack seems bigger and I am puzzled why.\n\nNot that I know much about the pack format, but is it possible that the \ndeltas are deflated? In that case, a possible explanation is that a better \ndelta is less compressible (and taken together, this could amount to more \nbytes).\n\nCiao,\nDscho\n"},{"id":"17253","messageId":"440C0F09.5060302@etek.chalmers.se","threadId":"3581","inReplyTo":"7v1wxg82r3.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Lukas Sandström","fromEmail":"lukass@etek.chalmers.se","sentAt":"2006-03-06T10:29:29Z","receivedAt":"2006-03-06T10:29:29Z","isPatch":false,"sender":{"key":"luksan@gmail.com","avatar":"https://avatars.githubusercontent.com/u/152281?v=4"},"body":"Junio C Hamano wrote:\n \n> I'd like asciidoc tweaks in \"next\" by Francis Daly tested by\n> people who have access to different vintages of docbook-xsl by\n> trying to build manpages. Look for displayed examples, such as\n> the one in git-branch documentation. I've tried it with v1.68\n> and getting far better results than before, and Francis says\n> v1.69 works fine with or without the change. IOW this is a\n> workaround for a problem in v1.68.\n> \n\nI tested it with asciidoc 7.0.1 and the examples in the git-branch \nman page look better with the fix.\n\n/Lukas\n\nBefore:\n Examples\n Start development off of a know tag\n\n\n $ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6 $\n cd my2.6 $ git branch my2.6.14 v2.6.14 $ git checkout my2.6.14\n\n These two steps are the same as \"checkout -b my2.6.14 v2.6.14\".\n\n Delete unneeded branch\n\n\n $ git clone git://git.kernel.org/.../git.git my.git $ cd my.git\n $ git branch -D todo\n\n delete todo branch even if the \"master\" branch does not have\n all commits from todo branch.\n\nAfter:\n Examples\n Start development off of a know tag\n\n $ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6\n $ cd my2.6\n $ git branch my2.6.14 v2.6.14\n $ git checkout my2.6.14\n\n These two steps are the same as \"checkout -b my2.6.14 v2.6.14\".\n\n\n Delete unneeded branch\n\n $ git clone git://git.kernel.org/.../git.git my.git\n $ cd my.git\n $ git branch -D todo\n\n delete todo branch even if the \"master\" branch does not have all\n commits from todo branch.\n"},{"id":"17426","messageId":"20060310104443.GA4491@c165.ib.student.liu.se","threadId":"3581","inReplyTo":"46a038f90603060105m29595745ke64d4a623506c0b0@mail.gmail.com","subject":"Re: What's in git.git","fromName":"Fredrik Kuivinen","fromEmail":"freku045@student.liu.se","sentAt":"2006-03-10T10:44:43Z","receivedAt":"2006-03-10T10:44:43Z","isPatch":false,"sender":{"key":"frekui@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13770967?v=4"},"body":"On Mon, Mar 06, 2006 at 10:05:41PM +1300, Martin Langhoff wrote:\n> On 3/6/06, Junio C Hamano wrote:\n> > - The deathmatch between annotate/blame (Ryan Anderson, Fredrik\n> > Kuivinen, me cheerleading)\n> \n> Add fuel to the fire ;-) Can git-blame take cached git-rev-list\n> output like annotate does with -S?\n> \n\nCurrently it cannot do that. How is that option used? If you want to\nmake annotate/blame faster for certain files you might as well cache\nthe output of annotate/blame instead of the git-rev-list output, no?\n\nWhat am I missing?\n\n- Fredrik\n"},{"id":"17429","messageId":"Pine.LNX.4.63.0603101215100.25810@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3581","inReplyTo":"20060310104443.GA4491@c165.ib.student.liu.se","subject":"Re: What's in git.git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-03-10T11:17:57Z","receivedAt":"2006-03-10T11:17:57Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 10 Mar 2006, Fredrik Kuivinen wrote:\n\n> On Mon, Mar 06, 2006 at 10:05:41PM +1300, Martin Langhoff wrote:\n> > On 3/6/06, Junio C Hamano wrote:\n> > > - The deathmatch between annotate/blame (Ryan Anderson, Fredrik\n> > > Kuivinen, me cheerleading)\n> > \n> > Add fuel to the fire ;-) Can git-blame take cached git-rev-list\n> > output like annotate does with -S?\n> > \n> \n> Currently it cannot do that. How is that option used?\n\nThe history is linearized, and the commits are ordered accordingly, then \nto be passed to git-annotate/-blame.\n\n> If you want to make annotate/blame faster for certain files you might as \n> well cache the output of annotate/blame instead of the git-rev-list \n> output, no?\n> \n> What am I missing?\n\nTwo things:\n\n- the history is growing, and\n- it would be inefficient/error-prone to save the annotates for files \n\nHth,\nDscho\n \n"},{"id":"17430","messageId":"46a038f90603100359o402d9e32j268e1b746d0bdfc8@mail.gmail.com","threadId":"3581","inReplyTo":"Pine.LNX.4.63.0603101215100.25810@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: What's in git.git","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2006-03-10T11:59:55Z","receivedAt":"2006-03-10T11:59:55Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 3/11/06, Johannes Schindelin wrote:\n> The history is linearized, and the commits are ordered accordingly, then\n> to be passed to git-annotate/-blame.\n\nExactly.\n\nIf a process has already done the costly git-rev-list for other\npurposes (say, grab logentries of the relevant commits), and wants to\nalso run annotate/blame, it should be able to reuse it cheaply, by\npassing -S filename. Possibly an IDE (or gitk/qgit) would want to do\nthis.\n\nNow, what I use it for in git-cvsserver is to \"flatten\" merges. CVS\nclients don't really understand that we know about parallel history,\nso every time we have a merge the view that the CVS client gets is of\na \"merge commit\" with a merge summary. And I sweep the merged commits\nunder the carpet.\n\n(there's some arbitrary nondeterministic magic in how I pick what side\nto track and what side to merge. let's not think about that too much.\nbut I just want git-blame to see a somewhat simplified git-rev-list).\n\ndoes that help?\n\ncheers,\n\n\nm\n"},{"id":"17502","messageId":"7vlkvfszu5.fsf@assigned-by-dhcp.cox.net","threadId":"3581","inReplyTo":"20060310104443.GA4491@c165.ib.student.liu.se","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-13T05:01:06Z","receivedAt":"2006-03-13T05:01:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Fredrik Kuivinen writes:\n\n> On Mon, Mar 06, 2006 at 10:05:41PM +1300, Martin Langhoff wrote:\n>> \n>> Add fuel to the fire ;-) Can git-blame take cached git-rev-list\n>> output like annotate does with -S?\n>\n> Currently it cannot do that. How is that option used? If you want to\n> make annotate/blame faster for certain files you might as well cache\n> the output of annotate/blame instead of the git-rev-list output, no?\n\nThere are two reasons Martin's git-cvsserver uses -S to feed you\nthe revision list. One is that he already has that ancestry\nchain information, and there is no point for him to have the\ngit-annotate command to recompute it.\n\nBut there is another, more important reason. He is giving his\nclients a modified world view where the branch he is exposing to\nhave _no_ merges -- just a single strand of pearls. So what is\nfed to git-annotate using -S from git-cvsserver has either one\nobject name (single root commit) or two (the commit and its sole\nparent). IOW, he does not want you to look at other parents\nwhen dealing with a merge commit.\n\nWhat this means is that in cases where your algorithm looked at\nsecond and subsequent parents to pass remaining blame on after\nlooking at the first parent for a merge, the algorithm now needs\nto assign the blame to the merge commit itself. Your\nprocess_commit() currently reads the commit object and loops\nover its true parents, but the -S flag wants to supply its own\nnotion of who are the parents of whom (and in the case of\ngit-cvsserver, it always supplies at most one parent) so you\nwould need to honor that instead of looking at the real\nancestry.\n"}]}