# Re: What's in git.git 8 messages from 2006-11-18 to 2006-11-19. Participants: Johannes Schindelin, Jakub Narebski, Junio C Hamano, Petr Baudis. Thread: https://gitlist.dev/t/43173 ## Junio C Hamano, 2006-11-18 22:24 Subject: What's in git.git Message-ID: <7v64dcbdgb.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v64dcbdgb.fsf%40assigned-by-dhcp.cox.net ``` Executive Summary - 'maint' and 'master' are the same, since we are still in "v1.4.4 fix" mood right now. A maintenance release v1.4.4.1 should follow soonish. - 'next' has a few 'these are obviously the right things to me but I want a bit of cheering-up before pushing them out, and they can wait until the dust settles after early fixes to v1.4.4 anyway' changes. - 'pu' has the shallow clone WIP and a half-finished rewrite of git branch in C, both by Johannes. Both needs a bit more polishing and confidence building before going into 'next', and given the recent discussion of enhancing branch management for pulls/pushes, it might be easier to drop the latter for now. I should also bring Shawn's piecemeal-mmap into 'pu'; I've looked at his code and it mostly looked sane. ---------------------------------------------------------------- * The 'maint' branch has these fixes since v1.4.4 release. The 'master' is the same as 'maint' right now. Alexandre Julliard: gitweb: Put back shortlog instead of graphiclog in the project list. Jim Meyering: Run "git repack -a -d" once more at end, if there's 1MB or more of not-packed data. Johannes Schindelin: Seek back to current filepos when mmap()ing with NO_MMAP Junio C Hamano: git-checkout: do not allow -f and -m at the same time. git-checkout: allow pathspec to recover lost working tree directory convert-objects: set _XOPEN_SOURCE to 600 Linus Torvalds: git-pull: allow pulling into an empty repository "git fmt-merge-msg" SIGSEGV Petr Baudis: Fix git-for-each-refs broken for tags git-apply: Documentation typo fix Documentation: Define symref and update HEAD description Rene Scharfe: sparse fix: non-ANSI function declaration sparse fix: Using plain integer as NULL pointer git-apply: slightly clean up bitfield usage Document git-runstatus * The 'next' branch, in addition, has these. Junio C Hamano upload-pack: stop the other side when they have more roots than we do. apply --numstat: mark binary diffstat with - -, not 0 0 pack-objects: tweak "do not even attempt delta" heuristics * The 'pu' branch, in addition, has these. Alexandre Julliard (1): Shallow clone: do not ignore shallowness when following tags Jakub Narebski (1): gitweb: New improved formatting of chunk header in diff Johannes Schindelin (6): upload-pack: no longer call rev-list support fetching into a shallow repository allow cloning a repository "shallowly" allow deepening of a shallow repository add tests for shallow stuff Build in shortlog Junio C Hamano (11): git-branch -a: show both local and remote tracking branches. git-commit: show --summary after successful commit. para-walk: walk n trees, index and working tree in parallel git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2) rev-list --left-right blame: --show-stats for easier optimization work. gitweb: steal loadavg throttle from kernel.org We should make sure that the protocol is still extensible. Why does it mean we do not have to register shallow if we have one? Why didn't we mark want_obj as ~UNINTERESTING in the old code? shallow clone: unparse and reparse an unshallowed commit ``` ## Junio C Hamano, 2006-11-18 23:14 Subject: Re: What's in git.git Message-ID: <7v1wo0bb4z.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7v1wo0bb4z.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <7v64dcbdgb.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano writes: > - 'pu' has the shallow clone WIP and a half-finished rewrite of > git branch in C, both by Johannes. Both needs a bit more > polishing and confidence building before going into 'next', > and given the recent discussion of enhancing branch > management for pulls/pushes, it might be easier to drop the > latter for now. OOPS; sorry but the latter half is entirely untrue. What's there is half-done git-shortlog. Scratch everything about branch management please. ``` ## Johannes Schindelin, 2006-11-19 15:17 Subject: Re: What's in git.git Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0611191547460.13772%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <7v1wo0bb4z.fsf@assigned-by-dhcp.cox.net> ``` Hi, On Sat, 18 Nov 2006, Junio C Hamano wrote: > Junio C Hamano writes: > > > - 'pu' has the shallow clone WIP and a half-finished rewrite of > > git branch in C, both by Johannes. Both needs a bit more > > polishing and confidence building before going into 'next', > > and given the recent discussion of enhancing branch > > management for pulls/pushes, it might be easier to drop the > > latter for now. > > OOPS; sorry but the latter half is entirely untrue. What's > there is half-done git-shortlog. Scratch everything about > branch management please. IMHO -shortlog needs support to read .mailmap, and maybe nods to throw out the built-in mailmap which is totally specific to the Linux kernel development. As for shallow clone support: I am a bit underwhelmed by the enthusiasm to test this thing by the people I thought would be most interested. It really could be the case that it is not needed at all. Just for the record, though: AFAICT the shallow stuff is lacking support for at least pushing from/into shallow repos and it should avoid making a commit shallow unnecessarily. And quite likely there are a few thinkos in it, so it would not hurt having more test cases (notably of things I did not think of), and some bad-ass testing with huge amounts of commits and files which were added/modified identically in different commits. Ciao, Dscho ``` ## Jakub Narebski, 2006-11-19 15:45 Subject: Re: What's in git.git Message-ID: URL: https://gitlist.dev/e/ejpu4r%24dsk%241%40sea.gmane.org In-Reply-To: ``` Johannes Schindelin wrote: > On Sat, 18 Nov 2006, Junio C Hamano wrote: > >> OOPS; sorry but the latter half is entirely untrue. What's >> there is half-done git-shortlog. Scratch everything about >> branch management please. > > IMHO -shortlog needs support to read .mailmap, and maybe nods to throw out > the built-in mailmap which is totally specific to the Linux kernel > development. If I remember correctly besides having built-in mailmap (at least in Perl version quite easy modificable, and updateable via Inline::Files), it also have built-in path shortening. And that part IIRC was not solved (although there was some proposal). The shallow clone work looks promising... -- Jakub Narebski Warsaw, Poland ShadeHawk on #git ``` ## Johannes Schindelin, 2006-11-19 16:30 Subject: Re: What's in git.git Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0611191729190.13772%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: ``` Hi, On Sun, 19 Nov 2006, Jakub Narebski wrote: > Johannes Schindelin wrote: > > > On Sat, 18 Nov 2006, Junio C Hamano wrote: > > > > IMHO -shortlog needs support to read .mailmap, and maybe nods to throw out > > the built-in mailmap which is totally specific to the Linux kernel > > development. See the 3 patches I just sent. > If I remember correctly besides having built-in mailmap (at least in Perl > version quite easy modificable, and updateable via Inline::Files), it also > have built-in path shortening. And that part IIRC was not solved (although > there was some proposal). I do not understand. What paths are handled by git-shortlog? Ciao, Dscho ``` ## Petr Baudis, 2006-11-19 17:01 Subject: Re: What's in git.git Message-ID: <20061119170123.GV7201@pasky.or.cz> URL: https://gitlist.dev/e/20061119170123.GV7201%40pasky.or.cz In-Reply-To: ``` On Sun, Nov 19, 2006 at 04:17:17PM CET, Johannes Schindelin wrote: > As for shallow clone support: I am a bit underwhelmed by the enthusiasm > to test this thing by the people I thought would be most interested. It > really could be the case that it is not needed at all. I was underwhelmed all the same by response to my multifetch work. Perhaps we need some better mechanism to get feedback from the downstream users which were main requesters of the $feature (I think that in both cases people can see how it could be useful generically but there's not too much immediate enthusiasm for playing with it inside the community). I think the main user of multifetch was xorg while the primary user of shallow clones would be Mozilla, right? It would be great if, when wishing for some large feature, they could say something like "if this ever gets done, please prod $mailinglist and we'll give it a stab and get you some feedback" (apparently there's noone from there monitoring the mailing list consistently, which is understandable though since it's not a too much low-traffic one). Alp? (xorg) Jon? (mozilla) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ The meaning of Stonehenge in Traflamadorian, when viewed from above, is: "Replacement part being rushed with all possible speed." ``` ## Jakub Narebski, 2006-11-19 18:31 Subject: Re: What's in git.git Message-ID: <200611191931.32193.jnareb@gmail.com> URL: https://gitlist.dev/e/200611191931.32193.jnareb%40gmail.com In-Reply-To: ``` Johannes Schindelin wrote: > I do not understand. What paths are handled by git-shortlog? I was under (perhaps false) impression that somewhere in git-shortlog there is shortening of Merge branch 'master' of git://git.kernel.org/pub/scm/git/git messages, shortening the URL part. Perhaps this was only other example of hard-coded git-for-Linux-ness. -- Jakub Narebski ``` ## Johannes Schindelin, 2006-11-19 19:06 Subject: Re: What's in git.git Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0611191932270.13772%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <200611191931.32193.jnareb@gmail.com> ``` Hi, On Sun, 19 Nov 2006, Jakub Narebski wrote: > Johannes Schindelin wrote: > > > I do not understand. What paths are handled by git-shortlog? > > I was under (perhaps false) impression that somewhere in git-shortlog > there is shortening of > Merge branch 'master' of git://git.kernel.org/pub/scm/git/git > messages, shortening the URL part. > > Perhaps this was only other example of hard-coded git-for-Linux-ness. I found it: git-shortlog.perl:28 says $desc =~ s#/pub/scm/linux/kernel/git/#/.../#g; And in builtin-shortlog.c:90 you can read const char *dot3 = "/pub/scm/linux/kernel/git/"; and in lines 133--136: while ((p = strstr(buffer, dot3)) != NULL) { memcpy(p, "...", 3); strcpy(p + 2, p + sizeof(dot3) - 1); } So, not only did I forget that git-shortlog has the path shortening, but I also forgot that I implemented it in the builtin shortlog, too. Ciao, Dscho ```