{"thread":{"id":"43088","subject":"What's in git.git","startedAt":"2006-11-08T03:21:24Z","lastAt":"2006-11-13T05:29:11Z","messageCount":20,"participants":["Junio C Hamano","Aneesh Kumar","Alexandre Julliard","Aneesh Kumar K.V","Sergey Vlasov","David Lang","Jakub Narebski","Johannes Schindelin","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"293830","messageId":"7v8ximwrm3.fsf@assigned-by-dhcp.cox.net","threadId":"43088","inReplyTo":null,"subject":"What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-08T03:21:24Z","receivedAt":"2006-11-08T03:21:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Executive Summary.\n\n[maint]\n\n I might do a 1.4.3.5 with the accumulated stuff, but the\n stablization cycle for v1.4.4 has started tonight, so it may\n not be worth the effort, unless something more pressing comes\n along.\n\n[master]\n\n Three topics that have been cooking in 'next' have been\n merged, I've tagged the tip as v1.4.4-rc1.\n\n - Nico and Shawn's keep-pack work;\n\n - Loosening of bogusly overstrict 'a working tree file will\n be overwritten by the merge' check;\n\n - git-pickaxe.\n\n[next]\n\n This now is almost empty, and I'd like to keep it that way\n until v1.4.5 final. IOW, I'd be happier if people sent in\n only obviously correct fixes to 'master' than seeing the next\n greatest feature ;-).\n\n By the way, do people mind if I start to rewind and rebase\n 'next' after every feature release (i.e. tagged release is\n made after 'master')? I do not feel a strong need for it, and\n 'git log --no-merges master..next' will show emptiness\n eventually, but being able to restart from clean slate after a\n release would be somewhat nice.\n\n[pu]\n\n Johannes's shallow clone work now should rebase cleanly on top\n of 'master' although I haven't done so yet. As he said\n himself the series is waiting for people who have needs for\n such a feature to raise hands.\n\n The part #2 of git-diff/git-apply change has a slight backward\n compatibility issue, and until everybody who is affected is\n upgraded to v1.4.3 (which has already prepared us for this\n change) we cannot push it out to 'master'. It adjusts the\n diff output header for files with SP in their names to what\n GNU patch accepts.\n\n----------------------------------------------------------------\n\n* The 'maint' branch has these fixes since the last announcement.\n\n Alex Riesen (1):\n merge-recursive implicitely depends on trust_executable_bit\n\n Andy Parkins (2):\n Minor grammar fixes for git-diff-index.txt\n git-clone documentation didn't mention --origin as equivalent of -o\n\n Jakub Narebski (1):\n Documentation: Transplanting branch with git-rebase --onto\n\n Jeff King (1):\n Fix git-runstatus for repositories containing a file named HEAD\n\n Johannes Schindelin (1):\n link_temp_to_file: call adjust_shared_perm() only when we created the directory\n\n Junio C Hamano (2):\n apply: handle \"traditional\" creation/deletion diff correctly.\n adjust_shared_perm: chmod() only when needed.\n\n Shawn O. Pearce (3):\n Use ULONG_MAX rather than implicit cast of -1.\n Remove SIMPLE_PROGRAMS and make git-daemon a normal program.\n Remove unsupported C99 style struct initializers in git-archive.\n\n Tero Roponen (1):\n remove an unneeded test\n\n* The 'master' branch has these since the last announcement.\n\n Alex Riesen (1):\n merge-recursive implicitely depends on trust_executable_bit\n\n Alexandre Julliard (5):\n pack-refs: Store the full name of the ref even when packing only tags.\n git.el: Added functions for moving to the next/prev unmerged file.\n git.el: Added a function to open the current file in another window.\n git.el: Move point after the log message header when entering log-edit mode.\n git.el: Include MERGE_MSG in the log-edit buffer even when not committing a merge.\n\n Andy Parkins (3):\n Remove uneccessarily similar printf() from print_ref_list() in builtin-branch\n Minor grammar fixes for git-diff-index.txt\n git-clone documentation didn't mention --origin as equivalent of -o\n\n Aneesh Kumar K.V (1):\n gitweb: Remove extra \"/\" in path names for git_get_project_list\n\n Eric Wong (2):\n git-svn: avoid printing filenames of files we're not tracking\n git-svn: don't die on rebuild when --upgrade is specified\n\n Jakub Narebski (4):\n gitweb: Use git-for-each-ref to generate list of heads and/or tags\n gitweb: Output also empty patches in \"commitdiff\" view\n gitweb: Better support for non-CSS aware web browsers\n Documentation: Transplanting branch with git-rebase --onto\n\n Jeff King (2):\n git-pickaxe: work properly in a subdirectory.\n Fix git-runstatus for repositories containing a file named HEAD\n\n Johannes Schindelin (1):\n link_temp_to_file: call adjust_shared_perm() only when we created the directory\n\n Junio C Hamano (40):\n git-pickaxe: blame rewritten.\n git-pickaxe -M: blame line movements within a file.\n git-pickaxe -C: blame cut-and-pasted lines.\n git-pickaxe: pagenate output by default.\n git-pickaxe: fix nth_line()\n git-pickaxe: improve \"best match\" heuristics\n git-pickaxe: introduce heuristics to avoid \"trivial\" chunks\n git-pickaxe: do not keep commit buffer.\n git-pickaxe: do not confuse two origins that are the same.\n git-pickaxe: get rid of wasteful find_origin().\n git-pickaxe: swap comparison loop used for -C\n merge: loosen overcautious \"working file will be lost\" check.\n merge-recursive: use abbreviated commit object name.\n merge-recursive: make a few functions static.\n merge-recursive: adjust to loosened \"working file clobbered\" check\n t6022: ignoring untracked files by merge-recursive when they do not matter\n send-pack --keep: do not explode into loose objects on the receiving end.\n git-pickaxe: WIP to refcount origin structure.\n git-pickaxe: allow -Ln,m as well as -L n,m\n git-pickaxe: refcount origin correctly in find_copy_in_parent()\n git-pickaxe: tighten sanity checks.\n Revert \"send-pack --keep: do not explode into loose objects on the receiving end.\"\n git-pickaxe: split find_origin() into find_rename() and find_origin().\n git-pickaxe: cache one already found path per commit.\n Introduce a new revision set operator ^!\n for-each-ref: \"creator\" and \"creatordate\" fields\n apply: handle \"traditional\" creation/deletion diff correctly.\n git-pickaxe: rename detection optimization\n git-pickaxe: simplify Octopus merges further\n git-pickaxe: re-scan the blob after making progress with -M\n git-pickaxe: re-scan the blob after making progress with -C\n git-pickaxe: fix origin refcounting\n cherry is built-in, do not ship git-cherry.sh\n git-blame: add internal statistics to count read blobs.\n git-pickaxe: optimize by avoiding repeated read_sha1_file().\n adjust_shared_perm: chmod() only when needed.\n Document git-pack-refs and link it to git(7).\n git-pickaxe: -L /regexp/,/regexp/\n git-pickaxe: allow \"-L ,+N\"\n GIT 1.4.3-rc1\n\n Linus Torvalds (2):\n Allow '-' in config variable names\n git push: add verbose flag and allow overriding of default target repository\n\n Nicolas Pitre (14):\n enable index-pack streaming capability\n make index-pack able to complete thin packs.\n add progress status to index-pack\n mimic unpack-objects when --stdin is used with index-pack\n enhance clone and fetch -k experience\n index-pack: minor fixes to comment and function name\n missing small substitution\n make git-push a bit more verbose\n Allow pack header preprocessing before unpack-objects/index-pack.\n git-fetch can use both --thin and --keep with fetch-pack now\n improve fetch-pack's handling of kept packs\n have index-pack create .keep file more carefully\n remove .keep pack lock files when done with refs update\n git-pack-objects progress flag documentation and cleanup\n\n Petr Baudis (1):\n gitweb: Support for 'forks'\n\n Sean Estabrooks (1):\n Add --global option to git-repo-config.\n\n Shawn O. Pearce (11):\n Added completion support for git-branch.exe.\n Added bash completion support for git-reset.\n Use ULONG_MAX rather than implicit cast of -1.\n Remove SIMPLE_PROGRAMS and make git-daemon a normal program.\n Remove unsupported C99 style struct initializers in git-archive.\n Added missing completions for show-branch and merge-base.\n Only load .exe suffix'd completions on Cygwin.\n Bash completion support for remotes in .git/config.\n Take --git-dir into consideration during bash completion.\n Support bash completion on symmetric difference operator.\n Remove more sed invocations from within bash completion.\n\n Shawn Pearce (5):\n Allow short pack names to git-pack-objects --unpacked=.\n Only repack active packs by skipping over kept packs.\n Teach git-index-pack how to keep a pack file.\n Remove unused variable in receive-pack.\n Teach receive-pack how to keep pack files based on object count.\n\n Tero Roponen (1):\n remove an unneeded test\n\n\n* The 'next' branch, in addition, has these.\n\n Junio C Hamano:\n upload-pack: stop the other side when they have more roots than we do.\n\n\n* The 'pu' branch, in addition, has these.\n\n Johannes Schindelin (6):\n Build in shortlog\n upload-pack: no longer call rev-list\n support fetching into a shallow repository\n allow cloning a repository \"shallowly\"\n allow deepening of a shallow repository\n add tests for shallow stuff\n\n Junio C Hamano (6):\n git-branch -a: show both local and remote tracking branches.\n git-commit: show --summary after successful commit.\n para-walk: walk n trees, index and working tree in parallel\n git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)\n rev-list --left-right\n blame and pickaxe: --show-stats for easier optimization work.\n\n"},{"id":"297029","messageId":"Pine.LNX.4.63.0611072009220.2601@qynat.qvtvafvgr.pbz","threadId":"43088","inReplyTo":"7v8ximwrm3.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"David Lang","fromEmail":"dlang@digitalinsight.com","sentAt":"2006-11-08T04:13:10Z","receivedAt":"2006-11-08T04:13:10Z","isPatch":false,"sender":{"key":"dlang@digitalinsight.com","avatar":null},"body":"On Tue, 7 Nov 2006, Junio C Hamano wrote:\n\n> [pu]\n>\n> Johannes's shallow clone work now should rebase cleanly on top\n> of 'master' although I haven't done so yet. As he said\n> himself the series is waiting for people who have needs for\n> such a feature to raise hands.\n\nI haven't been watching this recently, but if this is what I understand it to be \n(the ability to get a partial repository from upstream and work normally from \nthere with the result of data-mineing tools sometimes reporting 'that's part of \nthe truncated history' if they hit the cutoff) consider my hand raised.\n\nthere are a number of cases where I would be interested in following a project \nas it moves forwards, but do not have the need to have the full history (even \nwith the good compression that a git pack provides, it's still a significant \namount of disk space and download time for large projects)\n\n"},{"id":"298038","messageId":"eis1j6$vug$2@sea.gmane.org","threadId":"43088","inReplyTo":"7v8ximwrm3.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-08T07:40:07Z","receivedAt":"2006-11-08T07:40:07Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n>    Jakub Narebski (4):\n[...]\n>       gitweb: Output also empty patches in \"commitdiff\" view\n\nI think that this patch is a bit premature. Without \"new improved patchset\nview\" the empty patches are just that: totally empty. It is new header and\nespecially outputting extended header information which makes outputting\n\"empty\" patches (with no diff) in \"commitdiff\" view usefull. By \"empty\"\npatches I mean pure type change, pure rename, pure copy and type change and\nrename.\n\nThe \"new improved patchset view\" is prepared to send in two stages: updated\nfilename quoting/unquoting series (two patches: unescape + minimal\nesc_path; esc_path with span.cntrl and backslash sequence quoting), and\n\"new improved patchset view\" (three patches originally, two remains: using\n\"git diff\" header and extended git diff headers; output and link also to\npatches with empty diff; improved formatting of chunk header).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297270","messageId":"eis2m4$3i6$1@sea.gmane.org","threadId":"43088","inReplyTo":"7v8ximwrm3.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-08T07:58:44Z","receivedAt":"2006-11-08T07:58:44Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> [master]\n> \n>   Three topics that have been cooking in 'next' have been\n>   merged, I've tagged the tip as v1.4.4-rc1.\n\nBy the way, tag v1.4.4-rc1 has \"GIT 1.4.4-rc1\" as title, while the commit it\npoints to, v1.4.4-rc1^{} has \"GIT 1.4.3-rc1\" as a title.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"296225","messageId":"7vbqniv06i.fsf@assigned-by-dhcp.cox.net","threadId":"43088","inReplyTo":"eis1j6$vug$2@sea.gmane.org","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-08T07:59:17Z","receivedAt":"2006-11-08T07:59:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Junio C Hamano wrote:\n>\n>>    Jakub Narebski (4):\n> [...]\n>>       gitweb: Output also empty patches in \"commitdiff\" view\n>\n> I think that this patch is a bit premature. Without \"new improved patchset\n> view\" the empty patches are just that: totally empty. It is new header and\n> especially outputting extended header information which makes outputting\n> \"empty\" patches (with no diff) in \"commitdiff\" view usefull. By \"empty\"\n> patches I mean pure type change, pure rename, pure copy and type change and\n> rename.\n>\n> The \"new improved patchset view\" is prepared to send in two stages...\n\nAt least this does not break the page even without these two\nfollow-ups. If the follow-ups come in time and do not break the\npage, they are very welcome post -rc1 fixes to have before the\nfinal release. On the other hand, even if they don't, it's not\nthe end of the world ;-).\n\n"},{"id":"293927","messageId":"7vr6wetkc6.fsf@assigned-by-dhcp.cox.net","threadId":"43088","inReplyTo":"eis2m4$3i6$1@sea.gmane.org","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-08T08:26:49Z","receivedAt":"2006-11-08T08:26:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n> Junio C Hamano wrote:\n>\n>> [master]\n>> \n>>   Three topics that have been cooking in 'next' have been\n>>   merged, I've tagged the tip as v1.4.4-rc1.\n>\n> By the way, tag v1.4.4-rc1 has \"GIT 1.4.4-rc1\" as title, while the commit it\n> points to, v1.4.4-rc1^{} has \"GIT 1.4.3-rc1\" as a title.\n\nYeah, sometimes I make typoes. Not a news X-<.\n"},{"id":"298094","messageId":"20061108145157.GU20017@pasky.or.cz","threadId":"43088","inReplyTo":"7v8ximwrm3.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-08T14:51:57Z","receivedAt":"2006-11-08T14:51:57Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"> By the way, do people mind if I start to rewind and rebase\n> 'next' after every feature release (i.e. tagged release is\n> made after 'master')? I do not feel a strong need for it, and\n> 'git log --no-merges master..next' will show emptiness\n> eventually, but being able to restart from clean slate after a\n> release would be somewhat nice.\n\n It would be annoying for me since I can't mantain a long-term private\nbranch tracking next then (and I prefer next to master). I don't do that\nright now but I've done that shortly in the past and it would be nice to\nhave that possibility in the future as well.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i On Tue, 7 Nov 2006, Junio C Hamano wrote:\n> \n>> [pu]\n>>\n>> Johannes's shallow clone work now should rebase cleanly on top\n>> of 'master' although I haven't done so yet. As he said\n>> himself the series is waiting for people who have needs for\n>> such a feature to raise hands.\n> \n> I haven't been watching this recently, but if this is what I understand \n> it to be (the ability to get a partial repository from upstream and work \n> normally from there with the result of data-mineing tools sometimes \n> reporting 'that's part of the truncated history' if they hit the cutoff) \n> consider my hand raised.\n> \n> there are a number of cases where I would be interested in following a \n> project as it moves forwards, but do not have the need to have the full \n> history (even with the good compression that a git pack provides, it's \n> still a significant amount of disk space and download time for large \n> projects)\n> \n\nI am trying to test this feature. Is there a documentation .git/shallow some where. Atleast what those entries\nmean ? I know in the mail johannes mentioned only core git will touch this file. But it should be ok to be \ndescriptive like other files. (FETCH_HEAD)\n\n-aneesh \n"},{"id":"296463","messageId":"45521AE9.7050902@gmail.com","threadId":"43088","inReplyTo":"45520872.3090506@gmail.com","subject":"Re: Shallow clone [Was Re: What's in git.git ]","fromName":"Aneesh Kumar K.V","fromEmail":"aneesh.kumar@gmail.com","sentAt":"2006-11-08T17:59:05Z","receivedAt":"2006-11-08T17:59:05Z","isPatch":false,"sender":{"key":"aneesh.kumar@gmail.com","avatar":"https://gravatar.com/avatar/0621fc0b2f14ead1e9024382f16053a808c148596da30c1b92572fa075621f68?d=mp&s=160"},"body":"Aneesh Kumar K.V wrote:\n> David Lang wrote:\n>> On Tue, 7 Nov 2006, Junio C Hamano wrote:\n>>\n>>> [pu]\n>>>\n>>> Johannes's shallow clone work now should rebase cleanly on top\n>>> of 'master' although I haven't done so yet. As he said\n>>> himself the series is waiting for people who have needs for\n>>> such a feature to raise hands.\n>>\n>> I haven't been watching this recently, but if this is what I \n>> understand it to be (the ability to get a partial repository from \n>> upstream and work normally from there with the result of data-mineing \n>> tools sometimes reporting 'that's part of the truncated history' if \n>> they hit the cutoff) consider my hand raised.\n>>\n>> there are a number of cases where I would be interested in following a \n>> project as it moves forwards, but do not have the need to have the \n>> full history (even with the good compression that a git pack provides, \n>> it's still a significant amount of disk space and download time for \n>> large projects)\n>>\n> \n> I am trying to test this feature. Is there a documentation .git/shallow \n> some where. Atleast what those entries\n> mean ? I know in the mail johannes mentioned only core git will touch \n> this file. But it should be ok to be descriptive like other files. \n> (FETCH_HEAD)\n\n\nHow about this \n\n-aneesh \n\n\ndiff --git a/Documentation/repository-layout.txt b/Documentation/repository-layout.txt\nindex 275d18b..03a6f77 100644\n--- a/Documentation/repository-layout.txt\n+++ b/Documentation/repository-layout.txt\n@@ -141,3 +141,9 @@ logs/refs/heads/`name`::\n \n logs/refs/tags/`name`::\n \tRecords all changes made to the tag named `name`.\n+\n+shallow::\n+\tRecords the sha1 of the commits which is marked to have no\n+\tparents to represent a shallow repository.The commit object\n+\twill have the parent information present. It carry one\n+\trecord per line.\n"},{"id":"294909","messageId":"7virhpqyfj.fsf@assigned-by-dhcp.cox.net","threadId":"43088","inReplyTo":"7v8ximwrm3.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's in git.git","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-09T00:02:56Z","receivedAt":"2006-11-09T00:02:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sorry, I made a mistake of pushing out git-pickaxe before making\nit take over git-blame. So I will fix it up by renaming it to\ngit-blame.\n\nThat is, unless there are too many people whose fingers have\nalready been trained to type \"git-pickaxe\" from 'next'\nexperience (you can obviously count me as one of these people).\nIn which case I will keep git-pickaxe as a backward compatible\nsynonym just like we still have git-annotate.\n\nIt might also make sense to eventually remove the other synonym\ngit-annotate but that would be a longer term issue and should be\nhandled separately.\n"},{"id":"297769","messageId":"7vac31p8om.fsf@assigned-by-dhcp.cox.net","threadId":"43088","inReplyTo":"45521AE9.7050902@gmail.com","subject":"Re: Shallow clone","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-09T04:04:25Z","receivedAt":"2006-11-09T04:04:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Aneesh Kumar K.V\" writes:\n\n>> I am trying to test this feature. Is there a documentation\n>> .git/shallow some where. Atleast what those entries\n>> mean ? I know in the mail johannes mentioned only core git will\n>> touch this file. But it should be ok to be descriptive like other\n>> files. (FETCH_HEAD)\n>\n> diff --git a/Documentation/repository-layout.txt b/Documentation/repository-layout.txt\n> index 275d18b..03a6f77 100644\n> --- a/Documentation/repository-layout.txt\n> +++ b/Documentation/repository-layout.txt\n> @@ -141,3 +141,9 @@ logs/refs/heads/`name`::\n> \n> logs/refs/tags/`name`::\n> \tRecords all changes made to the tag named `name`.\n> +\n> +shallow::\n> +\tRecords the sha1 of the commits which is marked to have no\n> +\tparents to represent a shallow repository.The commit object\n> +\twill have the parent information present. It carry one\n> +\trecord per line.\n\nI would drop the second sentence which is just confusing but\notherwise it is correct, I think (I just started trying it\nout).\n\nBut it seems to need some more work. I just tried to clone\ngit.git with --depth=1 and it cauterizes each branch with two\ncommits (I think that is what depth=1 means -- the latest and\none behind it), but it pulled almost the whole repository\nanyway, and it turns out that \"git log v1.4.3-rc1\" gives me the\nfull history leading to it.\n\nSubsequent \"git fetch --depth 99999\" makes the branches\nconnected to the root commit, and I am reasonably sure we do not\nhave that many commits, but .git/shallow did not become empty.\n\nI haven't followed the code closely enough to tell if these are\njust minor details needing more polish, or something more\nfundamental in the design.\n\n\n"},{"id":"294114","messageId":"cc723f590611082017m1104fd66o595ec9db144cb2ce@mail.gmail.com","threadId":"43088","inReplyTo":"7vac31p8om.fsf@assigned-by-dhcp.cox.net","subject":"Re: Shallow clone","fromName":"Aneesh Kumar","fromEmail":"aneesh.kumar@gmail.com","sentAt":"2006-11-09T04:17:20Z","receivedAt":"2006-11-09T04:17:20Z","isPatch":false,"sender":{"key":"aneesh.kumar@gmail.com","avatar":"https://gravatar.com/avatar/0621fc0b2f14ead1e9024382f16053a808c148596da30c1b92572fa075621f68?d=mp&s=160"},"body":"On 11/9/06, Junio C Hamano wrote:\n> \"Aneesh Kumar K.V\" writes:\n>\n> >\n> But it seems to need some more work. I just tried to clone\n> git.git with --depth=1 and it cauterizes each branch with two\n> commits (I think that is what depth=1 means -- the latest and\n> one behind it), but it pulled almost the whole repository\n> anyway, and it turns out that \"git log v1.4.3-rc1\" gives me the\n> full history leading to it.\n>\n> Subsequent \"git fetch --depth 99999\" makes the branches\n> connected to the root commit, and I am reasonably sure we do not\n> have that many commits, but .git/shallow did not become empty.\n>\n\nI tried a local clone with --depth 2 and it showed two commits\nin all the branches/DAG. But then doing a pull --depth 4 listed more\ncommits than 4. I didn't look much into this.\n\n"},{"id":"296098","messageId":"87zmaynl18.fsf@wine.dyndns.org","threadId":"43088","inReplyTo":"7vac31p8om.fsf@assigned-by-dhcp.cox.net","subject":"Re: Shallow clone","fromName":"Alexandre Julliard","fromEmail":"julliard@winehq.org","sentAt":"2006-11-11T13:57:23Z","receivedAt":"2006-11-11T13:57:23Z","isPatch":false,"sender":{"key":"julliard@winehq.org","avatar":null},"body":"Junio C Hamano writes:\n\n> But it seems to need some more work. I just tried to clone\n> git.git with --depth=1 and it cauterizes each branch with two\n> commits (I think that is what depth=1 means -- the latest and\n> one behind it), but it pulled almost the whole repository\n> anyway, and it turns out that \"git log v1.4.3-rc1\" gives me the\n> full history leading to it.\n\nThat's apparently because tags are not considered when truncating the\ncommit list. The patch below fixes it, and fetches the right number of\ncommits for each tag. However the correct fix is probably to not fetch\nhistorical tags at all.\n\nThere's also a problem with the packing, a clone --depth 1 currently\nresults in a pack that's about 3 times as large as it should be.\n\n---\ndiff --git a/shallow.c b/shallow.c\nindex 58a7b20..2db1dc4 100644\n--- a/shallow.c\n+++ b/shallow.c\n@@ -1,5 +1,6 @@\n #include \"cache.h\"\n #include \"commit.h\"\n+#include \"tag.h\"\n \n static int is_shallow = -1;\n \n@@ -54,7 +55,7 @@ struct commit_list *get_shallow_commits(\n \t\tif (!commit) {\n \t\t\tif (i < heads->nr) {\n \t\t\t\tcommit = (struct commit *)\n-\t\t\t\t\theads->objects[i++].item;\n+\t\t\t\t\tderef_tag(heads->objects[i++].item, NULL, 0);\n \t\t\t\tif (commit->object.type != OBJ_COMMIT) {\n \t\t\t\t\tcommit = NULL;\n \t\t\t\t\tcontinue;\n\n-- \nAlexandre Julliard\n"},{"id":"294778","messageId":"7vu015f5av.fsf@assigned-by-dhcp.cox.net","threadId":"43088","inReplyTo":"87zmaynl18.fsf@wine.dyndns.org","subject":"Re: Shallow clone","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-12T08:16:40Z","receivedAt":"2006-11-12T08:16:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Alexandre Julliard writes:\n\n> There's also a problem with the packing, a clone --depth 1 currently\n> results in a pack that's about 3 times as large as it should be.\n\nThat's interesting.\n\n : gitster; git clone -n --depth 1 git://127.0.0.1/git.git victim-001\n remote: Generating pack...\n remote: Done counting 6246 objects.\n remote: Deltifying 6246 objects.\n remote: 100% (6246/6246) done\n Indexing 6246 objects.\n remote: Total 6246, written 6246 (delta 3106), reused 4313 (delta 3106)\n 100% (6246/6246) done\n Resolving 3106 deltas.\n 100% (3106/3106) done\n : gitster; cd victim-001\n : gitster; ls -lh .git/objects/pack/\n total 9.6M\n drwxrwsr-x 2 junio src 4.0K 2006-11-11 23:52 ./\n drwxrwsr-x 4 junio src 4.0K 2006-11-11 23:52 ../\n -r--r--r-- 1 junio src 148K 2006-11-11 23:52 pack-f5f88d83....idx\n -r--r--r-- 1 junio src 9.5M 2006-11-11 23:52 pack-f5f88d83....pack\n\nRepacking immediately after cloning brings it down to what is\nexpected.\n\n : gitster; git repack -a -d -f\n Generating pack...\n Done counting 6246 objects.\n Deltifying 6246 objects.\n 100% (6246/6246) done\n Writing 6246 objects.\n 100% (6246/6246) done\n Total 6246, written 6246 (delta 4815), reused 1407 (delta 0)\n Pack pack-f5f88d83524213e3ab05697ff75f245b1ef9081a created.\n : gitster; ls -lh .git/objects/pack/\n total 2.8M\n drwxrwsr-x 2 junio src 4.0K 2006-11-11 23:53 ./\n drwxrwsr-x 4 junio src 4.0K 2006-11-11 23:52 ../\n -rw-rw-r-- 1 junio src 148K 2006-11-11 23:53 pack-f5f88d83....idx\n -rw-rw-r-- 1 junio src 2.6M 2006-11-11 23:53 pack-f5f88d83....pack\n\nIn any case, after this \"shallow\" stuff, repeated \"fetch --depth\n99\" seems to fetch 0 object and 3400 objects alternately, and\nthe shallow file alternates between 900 bytes and 11000 bytes.\n\nWe would need to take a deeper look into what this series does,\nbefore moving it to 'next'.\n\n\n\n"},{"id":"297573","messageId":"20061112131209.GC7201@pasky.or.cz","threadId":"43088","inReplyTo":"45521AE9.7050902@gmail.com","subject":"Re: Shallow clone [Was Re: What's in git.git ]","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-12T13:12:09Z","receivedAt":"2006-11-12T13:12:09Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Nov 08, 2006 at 06:59:05PM CET, Aneesh Kumar K.V wrote:\n> diff --git a/Documentation/repository-layout.txt b/Documentation/repository-layout.txt\n> index 275d18b..03a6f77 100644\n> --- a/Documentation/repository-layout.txt\n> +++ b/Documentation/repository-layout.txt\n> @@ -141,3 +141,9 @@ logs/refs/heads/`name`::\n> \n> logs/refs/tags/`name`::\n> \tRecords all changes made to the tag named `name`.\n> +\n> +shallow::\n\nHmm, shouldn't the shallow file rather belong to the info/ subdirectory?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Alexandre Julliard writes:\n>\n> > There's also a problem with the packing, a clone --depth 1 currently\n> > results in a pack that's about 3 times as large as it should be.\n>\n> That's interesting.\n>\n> : gitster; git clone -n --depth 1 git://127.0.0.1/git.git victim-001\n[...]\n> -r--r--r-- 1 junio src 9.5M 2006-11-11 23:52 pack-f5f88d83....pack\n>\n> Repacking immediately after cloning brings it down to what is\n> expected.\n>\n> : gitster; git repack -a -d -f\n[...]\n> -rw-rw-r-- 1 junio src 2.6M 2006-11-11 23:53 pack-f5f88d83....pack\n\nThis is due to optimization in builtin-pack-objects.c:try_delta():\n\n\t/*\n\t * We do not bother to try a delta that we discarded\n\t * on an earlier try, but only when reusing delta data.\n\t */\n\tif (!no_reuse_delta && trg_entry->in_pack &&\n\t trg_entry->in_pack == src_entry->in_pack)\n\t\treturn 0;\n\nAfter removing this part the shallow pack after clone is 2.6M, as it\nshould be.\n\nThe problem with this optimization is that it is only valid if we are\nrepacking either the same set of objects as we did earlier, or its\nsuperset. But if we are packing a subset of objects, there will be some\nobjects in that subset which were delta-compressed in the original pack,\nbut base objects for that deltas are not included in our subset -\ntherefore we will be unable to reuse existing deltas, and with that\noptimization we will never try to use delta compression for these\nobjects. (The optimization assumes that if we will try to use delta\ncompression, we will try mostly the same base objects as we have tried\nwhen we made the existing pack, and therefore will likely get the same\nresult - which is close to the truth when we are doing \"repack -a\", but\nis badly wrong when we are doing \"git-upload-pack\" with a large number\nof common commits, and therefore are excluding a lot of objects.)\n\nSo any partial fetch (shallow or not) from a mostly packed repository\ncurrently results in a suboptimal pack. In fact, the fresh \"repack -a\n-d -f\" is probably the worst case for subsequent fetch (not initial\nclone) from that repository - objects for the most recent commit are\nmost likely to be stored without delta compression, and even if deltas\nare used, they are likely in the wrong direction for someone who has an\nolder version and wants to update it.\n\n\n> In any case, after this \"shallow\" stuff, repeated \"fetch --depth\n> 99\" seems to fetch 0 object and 3400 objects alternately, and\n> the shallow file alternates between 900 bytes and 11000 bytes.\n\nI confirm this - different numbers, but the same problem...\n"},{"id":"295005","messageId":"7vodrcctyd.fsf@assigned-by-dhcp.cox.net","threadId":"43088","inReplyTo":"20061112131209.GC7201@pasky.or.cz","subject":"Re: Shallow clone","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-12T20:04:42Z","receivedAt":"2006-11-12T20:04:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> On Wed, Nov 08, 2006 at 06:59:05PM CET, Aneesh Kumar K.V wrote:\n>> diff --git a/Documentation/repository-layout.txt b/Documentation/repository-layout.txt\n>> index 275d18b..03a6f77 100644\n>> --- a/Documentation/repository-layout.txt\n>> +++ b/Documentation/repository-layout.txt\n>> @@ -141,3 +141,9 @@ logs/refs/heads/`name`::\n>> \n>> logs/refs/tags/`name`::\n>> \tRecords all changes made to the tag named `name`.\n>> +\n>> +shallow::\n>\n> Hmm, shouldn't the shallow file rather belong to the info/ subdirectory?\n\nI think that makes sense.\n"},{"id":"296431","messageId":"7vd57scong.fsf@assigned-by-dhcp.cox.net","threadId":"43088","inReplyTo":"20061112205909.f8951300.vsu@altlinux.ru","subject":"Re: Shallow clone","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-12T21:59:15Z","receivedAt":"2006-11-12T21:59:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sergey Vlasov writes:\n\n> This is due to optimization in builtin-pack-objects.c:try_delta():\n>\n> \t/*\n> \t * We do not bother to try a delta that we discarded\n> \t * on an earlier try, but only when reusing delta data.\n> \t */\n> \tif (!no_reuse_delta && trg_entry->in_pack &&\n> \t trg_entry->in_pack == src_entry->in_pack)\n> \t\treturn 0;\n>\n> After removing this part the shallow pack after clone is 2.6M, as it\n> should be.\n>\n> The problem with this optimization is that it is only valid if we are\n> repacking either the same set of objects as we did earlier, or its\n> superset. But if we are packing a subset of objects, there will be some\n> objects in that subset which were delta-compressed in the original pack,\n> but base objects for that deltas are not included in our subset -\n> therefore we will be unable to reuse existing deltas, and with that\n> optimization we will never try to use delta compression for these\n> objects.\n> ...\n> So any partial fetch (shallow or not) from a mostly packed repository\n> currently results in a suboptimal pack.\n\nThat is correct. How about something like this?\n\nI think the determination of \"repacking_superset\" may need to be\ntweaked because existing packs may have overlaps, and the patch\ncounts them once per pack.\n\n\ndiff --git a/builtin-pack-objects.c b/builtin-pack-objects.c\nindex 69e5dd3..fb25124 100644\n--- a/builtin-pack-objects.c\n+++ b/builtin-pack-objects.c\n@@ -64,6 +64,7 @@ struct object_entry {\n static unsigned char object_list_sha1[20];\n static int non_empty;\n static int no_reuse_delta;\n+static int repacking_superset;\n static int local;\n static int incremental;\n static int allow_ofs_delta;\n@@ -1172,10 +1173,13 @@ static int try_delta(struct unpacked *tr\n \t\treturn -1;\n \n \t/*\n-\t * We do not bother to try a delta that we discarded\n-\t * on an earlier try, but only when reusing delta data.\n+\t * When we are packing the superset of objects we have already\n+\t * packed, we do not bother to try a delta that we discarded\n+\t * on an earlier try. This heuristic of course should not\n+\t * kick in when we are not reusing delta, or we know we are\n+\t * sending a subset of objects from a repository.\n \t */\n-\tif (!no_reuse_delta && trg_entry->in_pack &&\n+\tif (!no_reuse_delta && repacking_superset && trg_entry->in_pack &&\n \t trg_entry->in_pack == src_entry->in_pack)\n \t\treturn 0;\n \n@@ -1493,6 +1497,16 @@ static void get_object_list(int ac, cons\n \ttraverse_commit_list(&revs, show_commit, show_object);\n }\n \n+static int count_packed_objects(void)\n+{\n+\tstruct packed_git *p;\n+\tint cnt = 0;\n+\n+\tfor (p = packed_git; p; p = p->next)\n+\t\tcnt += num_packed_objects(p);\n+\treturn cnt;\n+}\n+\n int cmd_pack_objects(int argc, const char **argv, const char *prefix)\n {\n \tSHA_CTX ctx;\n@@ -1631,6 +1645,8 @@ int cmd_pack_objects(int argc, const cha\n \tif (non_empty && !nr_result)\n \t\treturn 0;\n \n+\trepacking_superset = count_packed_objects() < nr_result;\n+\n \tSHA1_Init(&ctx);\n \tlist = sorted_by_sha;\n \tfor (i = 0; i < nr_result; i++) {\n\n"},{"id":"297512","messageId":"Pine.LNX.4.63.0611122319340.13772@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43088","inReplyTo":"Pine.LNX.4.63.0611072009220.2601@qynat.qvtvafvgr.pbz","subject":"Re: What's in git.git","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-12T22:25:29Z","receivedAt":"2006-11-12T22:25:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 7 Nov 2006, David Lang wrote:\n\n> On Tue, 7 Nov 2006, Junio C Hamano wrote:\n> \n> > [pu]\n> > \n> > Johannes's shallow clone work now should rebase cleanly on top\n> > of 'master' although I haven't done so yet. As he said\n> > himself the series is waiting for people who have needs for\n> > such a feature to raise hands.\n> \n> I haven't been watching this recently, but if this is what I understand it to\n> be (the ability to get a partial repository from upstream and work normally\n> from there with the result of data-mineing tools sometimes reporting 'that's\n> part of the truncated history' if they hit the cutoff) consider my hand\n> raised.\n\nFor now, it does not say \"part of the truncated history\". But yes, shallow \nclones are partial copies of remote repositories, by making some commits \n\"shallow\", i.e. grafting an empty set of parents onto them (thereby \npretending that these commits are root commits).\n\nTelling the user that a commit is shallow should not be too hard.\n\nCiao,\nDscho\n"},{"id":"295472","messageId":"7vodrbap94.fsf@assigned-by-dhcp.cox.net","threadId":"43088","inReplyTo":"7vd57scong.fsf@assigned-by-dhcp.cox.net","subject":"Re: Shallow clone","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-13T05:29:11Z","receivedAt":"2006-11-13T05:29:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Sergey Vlasov writes:\n>\n>> This is due to optimization in builtin-pack-objects.c:try_delta():\n>>\n>> \t/*\n>> \t * We do not bother to try a delta that we discarded\n>> \t * on an earlier try, but only when reusing delta data.\n>> \t */\n>> \tif (!no_reuse_delta && trg_entry->in_pack &&\n>> \t trg_entry->in_pack == src_entry->in_pack)\n>> \t\treturn 0;\n>>\n>> After removing this part the shallow pack after clone is 2.6M, as it\n>> should be.\n>>\n>> The problem with this optimization is that it is only valid if we are\n>> repacking either the same set of objects as we did earlier, or its\n>> superset. But if we are packing a subset of objects, there will be some\n>> objects in that subset which were delta-compressed in the original pack,\n>> but base objects for that deltas are not included in our subset -\n>> therefore we will be unable to reuse existing deltas, and with that\n>> optimization we will never try to use delta compression for these\n>> objects.\n>> ...\n>> So any partial fetch (shallow or not) from a mostly packed repository\n>> currently results in a suboptimal pack.\n\nWhat we tried to avoid with the original heuristics in commit\n51d1e83f was to avoid wasting time on undeltifiable blobs, and\nthey would be stored as base in the original packs, so I think\nthe following would fly better (the patch is for maint, for\nmaster we would also check for OBJ_REF_DELTA as well).\n\n---\n\ndiff --git a/builtin-pack-objects.c b/builtin-pack-objects.c\nindex 96c069a..84a8749 100644\n--- a/builtin-pack-objects.c\n+++ b/builtin-pack-objects.c\n@@ -1101,7 +1101,8 @@ static int try_delta(struct unpacked *tr\n \t * on an earlier try, but only when reusing delta data.\n \t */\n \tif (!no_reuse_delta && trg_entry->in_pack &&\n-\t trg_entry->in_pack == src_entry->in_pack)\n+\t trg_entry->in_pack == src_entry->in_pack &&\n+\t trg_entry->in_pack_type != OBJ_DELTA)\n \t\treturn 0;\n \n \t/*\n\n\n\n"}]}