# What's in git.git 9 messages from 2006-03-06 to 2006-03-13. Participants: Junio C Hamano, Martin Langhoff, Johannes Schindelin, Lukas Sandström, Fredrik Kuivinen. Thread: https://gitlist.dev/t/3581 ## Junio C Hamano, 2006-03-06 07:13 Subject: What's in git.git Message-ID: <7v1wxg82r3.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v1wxg82r3.fsf%40assigned-by-dhcp.cox.net ``` The "deathmatch" between Ryan's annotate and Fredrik's blame is officially on. Currently the last test in all three branches fail. Please do not get alarmed. I'd like asciidoc tweaks in "next" by Francis Daly tested by people who have access to different vintages of docbook-xsl by trying to build manpages. Look for displayed examples, such as the one in git-branch documentation. I've tried it with v1.68 and getting far better results than before, and Francis says v1.69 works fine with or without the change. IOW this is a workaround for a problem in v1.68. I've been tweaking on-and-off the similarity estimator in the "next" branch. It has become independent from the xdelta code used for pack generation. It may detect more renames that it missed before, and it may miss some other renames and copies. In general, it seems that the algorithm tends to detect slightly more breaks than before. I'd appreciate feedback from people interested in this area. Another thing I have started in "pu" branch is to stop placing an object we decided to delta that is already max-depth deep back in the delta-base window, because such a thing only wastes the delta base slot. The changed pack-objects does pick up more delta, but the resulting pack seems bigger and I am puzzled why. This may suggest that our criteria to delta should be tightened a bit (the value of max_size in try_delta should be decreased). We are better off storing a plain deflated representation instad of generating a bad, bigger delta. Insights? -- -- -- * The 'master' branch has these since the last announcement. - Documentation fixes (Dmitry V. Levin, Mark Wooding, Martin Langhoff, Jeff Muizelaar) git/Documentation: fix SYNOPSIS style bugs Documentation/Makefile: Some `git-*.txt' files aren't manpages. cvsserver: updated documentation cosmetics: change from 'See-Also' to 'See Also' documentation: add 'see also' sections to git-rm and git-add - The deathmatch between annotate/blame (Ryan Anderson, Fredrik Kuivinen, me cheerleading) annotate: Support annotation of files on other revisions. git-blame: Make the output human readable git-blame: Use the same tests for git-blame as for git-annotate blame: avoid -lm by not using log(). blame and annotate: show localtime with timezone. blame: avoid "diff -u0". annotate/blame tests updates. annotate-blame test: don't "source", but say "." annotate-blame test: add evil merge. - Tweak rev-list (Linus Torvalds) get_revision(): do not dig deeper when we know we are at the end. - Fix git-commit --amend (me) git-commit --amend: allow empty commit. - Misc fixes and cleanups (Mark Wooding and me) gitignore: Ignore some more boring things. contrib/emacs/Makefile: Provide tool for byte-compiling files. Const tightening. * The 'next' branch, in addition, has these. - Fix manpage formatting (Francis Daly) Tweak asciidoc output to work with broken docbook-xsl - Tweak break/rename/copy similarity estimator tweaks (me) diffcore-rename: similarity estimator fix. count-delta: no need for this anymore. diffcore-break: similarity estimator fix. diffcore-delta: make change counter to byte oriented again. - Help pack generation tweaks (me) verify-pack -v: show delta-chain histogram. - checkout-index --temp (Shawn Pearce) Add --temp and --stage=all options to checkout-index. * The 'pu' branch, in addition, has these. - WIP: pack generation tweak (me) [WIP] do not waste delta window with objects with already at max-depth. ``` ## Junio C Hamano, 2006-03-06 08:45 Subject: [PATCH] blame: unbreak "diff -U 0". Message-ID: <7vr75g6jxu.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vr75g6jxu.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7v1wxg82r3.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano writes: > The "deathmatch" between Ryan's annotate and Fredrik's blame is > officially on. Currently the last test in all three branches > fail. Please do not get alarmed. It turns out the breakage was caused after merging Fredrik's improvements. I'm double-checking the fix and will be pushing out corrected "master", "next" and "pu" shortly. Sorry, Fredrik. -- >8 -- Subject: [PATCH] blame: unbreak "diff -U 0". The commit 604c86d15bb319a1e93ba218fca48ce1c500ae52 changed the original "diff -u0" to "diff -u -U 0" for portability. A big mistake without proper testing. The form "diff -u -U 0" shows the default 3-line contexts, because -u and -U 0 contradicts with each other; "diff -U 0" (or its longhand "diff --unified=0") is what we meant. Signed-off-by: Junio C Hamano --- blame.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) 690e307f54b4aa84349b89e8552b25e7495f1cd6 diff --git a/blame.c b/blame.c index fca22f9..90338af 100644 --- a/blame.c +++ b/blame.c @@ -92,7 +92,7 @@ static struct patch *get_patch(struct co die("write failed: %s", strerror(errno)); close(fd); - sprintf(diff_cmd, "diff -u -U 0 %s %s", tmp_path1, tmp_path2); + sprintf(diff_cmd, "diff -U 0 %s %s", tmp_path1, tmp_path2); fin = popen(diff_cmd, "r"); if (!fin) die("popen failed: %s", strerror(errno)); @@ -234,7 +234,7 @@ static void print_patch(struct patch *p) } } -#if 0 +#if DEBUG /* For debugging only */ static void print_map(struct commit *cmit, struct commit *other) { -- 1.2.4.g3bcd ``` ## Martin Langhoff, 2006-03-06 09:05 Subject: Re: What's in git.git Message-ID: <46a038f90603060105m29595745ke64d4a623506c0b0@mail.gmail.com> URL: https://gitlist.dev/e/46a038f90603060105m29595745ke64d4a623506c0b0%40mail.gmail.com In-Reply-To: <7v1wxg82r3.fsf@assigned-by-dhcp.cox.net> ``` On 3/6/06, Junio C Hamano wrote: > - The deathmatch between annotate/blame (Ryan Anderson, Fredrik > Kuivinen, me cheerleading) Add fuel to the fire ;-) Can git-blame take cached git-rev-list output like annotate does with -S? m ``` ## Johannes Schindelin, 2006-03-06 09:15 Subject: Re: What's in git.git Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0603061012120.1422%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <7v1wxg82r3.fsf@assigned-by-dhcp.cox.net> ``` Hi, On Sun, 5 Mar 2006, Junio C Hamano wrote: > Another thing I have started in "pu" branch is to stop placing > an object we decided to delta that is already max-depth deep > back in the delta-base window, because such a thing only wastes > the delta base slot. The changed pack-objects does pick up more > delta, but the resulting pack seems bigger and I am puzzled why. Not that I know much about the pack format, but is it possible that the deltas are deflated? In that case, a possible explanation is that a better delta is less compressible (and taken together, this could amount to more bytes). Ciao, Dscho ``` ## Lukas Sandström, 2006-03-06 10:29 Subject: Re: What's in git.git Message-ID: <440C0F09.5060302@etek.chalmers.se> URL: https://gitlist.dev/e/440C0F09.5060302%40etek.chalmers.se In-Reply-To: <7v1wxg82r3.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > I'd like asciidoc tweaks in "next" by Francis Daly tested by > people who have access to different vintages of docbook-xsl by > trying to build manpages. Look for displayed examples, such as > the one in git-branch documentation. I've tried it with v1.68 > and getting far better results than before, and Francis says > v1.69 works fine with or without the change. IOW this is a > workaround for a problem in v1.68. > I tested it with asciidoc 7.0.1 and the examples in the git-branch man page look better with the fix. /Lukas Before: Examples Start development off of a know tag $ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6 $ cd my2.6 $ git branch my2.6.14 v2.6.14 $ git checkout my2.6.14 These two steps are the same as "checkout -b my2.6.14 v2.6.14". Delete unneeded branch $ git clone git://git.kernel.org/.../git.git my.git $ cd my.git $ git branch -D todo delete todo branch even if the "master" branch does not have all commits from todo branch. After: Examples Start development off of a know tag $ git clone git://git.kernel.org/pub/scm/.../linux-2.6 my2.6 $ cd my2.6 $ git branch my2.6.14 v2.6.14 $ git checkout my2.6.14 These two steps are the same as "checkout -b my2.6.14 v2.6.14". Delete unneeded branch $ git clone git://git.kernel.org/.../git.git my.git $ cd my.git $ git branch -D todo delete todo branch even if the "master" branch does not have all commits from todo branch. ``` ## Fredrik Kuivinen, 2006-03-10 10:44 Subject: Re: What's in git.git Message-ID: <20060310104443.GA4491@c165.ib.student.liu.se> URL: https://gitlist.dev/e/20060310104443.GA4491%40c165.ib.student.liu.se In-Reply-To: <46a038f90603060105m29595745ke64d4a623506c0b0@mail.gmail.com> ``` On Mon, Mar 06, 2006 at 10:05:41PM +1300, Martin Langhoff wrote: > On 3/6/06, Junio C Hamano wrote: > > - The deathmatch between annotate/blame (Ryan Anderson, Fredrik > > Kuivinen, me cheerleading) > > Add fuel to the fire ;-) Can git-blame take cached git-rev-list > output like annotate does with -S? > Currently it cannot do that. How is that option used? If you want to make annotate/blame faster for certain files you might as well cache the output of annotate/blame instead of the git-rev-list output, no? What am I missing? - Fredrik ``` ## Johannes Schindelin, 2006-03-10 11:17 Subject: Re: What's in git.git Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0603101215100.25810%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <20060310104443.GA4491@c165.ib.student.liu.se> ``` Hi, On Fri, 10 Mar 2006, Fredrik Kuivinen wrote: > On Mon, Mar 06, 2006 at 10:05:41PM +1300, Martin Langhoff wrote: > > On 3/6/06, Junio C Hamano wrote: > > > - The deathmatch between annotate/blame (Ryan Anderson, Fredrik > > > Kuivinen, me cheerleading) > > > > Add fuel to the fire ;-) Can git-blame take cached git-rev-list > > output like annotate does with -S? > > > > Currently it cannot do that. How is that option used? The history is linearized, and the commits are ordered accordingly, then to be passed to git-annotate/-blame. > If you want to make annotate/blame faster for certain files you might as > well cache the output of annotate/blame instead of the git-rev-list > output, no? > > What am I missing? Two things: - the history is growing, and - it would be inefficient/error-prone to save the annotates for files Hth, Dscho ``` ## Martin Langhoff, 2006-03-10 11:59 Subject: Re: What's in git.git Message-ID: <46a038f90603100359o402d9e32j268e1b746d0bdfc8@mail.gmail.com> URL: https://gitlist.dev/e/46a038f90603100359o402d9e32j268e1b746d0bdfc8%40mail.gmail.com In-Reply-To: ``` On 3/11/06, Johannes Schindelin wrote: > The history is linearized, and the commits are ordered accordingly, then > to be passed to git-annotate/-blame. Exactly. If a process has already done the costly git-rev-list for other purposes (say, grab logentries of the relevant commits), and wants to also run annotate/blame, it should be able to reuse it cheaply, by passing -S filename. Possibly an IDE (or gitk/qgit) would want to do this. Now, what I use it for in git-cvsserver is to "flatten" merges. CVS clients don't really understand that we know about parallel history, so every time we have a merge the view that the CVS client gets is of a "merge commit" with a merge summary. And I sweep the merged commits under the carpet. (there's some arbitrary nondeterministic magic in how I pick what side to track and what side to merge. let's not think about that too much. but I just want git-blame to see a somewhat simplified git-rev-list). does that help? cheers, m ``` ## Junio C Hamano, 2006-03-13 05:01 Subject: Re: What's in git.git Message-ID: <7vlkvfszu5.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vlkvfszu5.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20060310104443.GA4491@c165.ib.student.liu.se> ``` Fredrik Kuivinen writes: > On Mon, Mar 06, 2006 at 10:05:41PM +1300, Martin Langhoff wrote: >> >> Add fuel to the fire ;-) Can git-blame take cached git-rev-list >> output like annotate does with -S? > > Currently it cannot do that. How is that option used? If you want to > make annotate/blame faster for certain files you might as well cache > the output of annotate/blame instead of the git-rev-list output, no? There are two reasons Martin's git-cvsserver uses -S to feed you the revision list. One is that he already has that ancestry chain information, and there is no point for him to have the git-annotate command to recompute it. But there is another, more important reason. He is giving his clients a modified world view where the branch he is exposing to have _no_ merges -- just a single strand of pearls. So what is fed to git-annotate using -S from git-cvsserver has either one object name (single root commit) or two (the commit and its sole parent). IOW, he does not want you to look at other parents when dealing with a merge commit. What this means is that in cases where your algorithm looked at second and subsequent parents to pass remaining blame on after looking at the first parent for a merge, the algorithm now needs to assign the blame to the merge commit itself. Your process_commit() currently reads the commit object and loops over its true parents, but the -S flag wants to supply its own notion of who are the parents of whom (and in the case of git-cvsserver, it always supplies at most one parent) so you would need to honor that instead of looking at the real ancestry. ```