{"thread":{"id":"43469","subject":"What's cooking in git.git (topics)","startedAt":"2006-12-06T21:19:06Z","lastAt":"2006-12-08T10:12:56Z","messageCount":9,"participants":["Junio C Hamano","Jakub Narebski","Aneesh Kumar K.V","Andy Parkins","Johannes Schindelin","Alexandre Julliard"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"294959","messageId":"7vvekoyb79.fsf@assigned-by-dhcp.cox.net","threadId":"43469","inReplyTo":null,"subject":"What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-06T21:19:06Z","receivedAt":"2006-12-06T21:19:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Here is a list of topics that are cooking; the commits marked\nwith '+' are in 'next', '-' are in 'pu'.  Dates are when the\ntopic was last touched [*1*].\n\n----------------------------------------------------------------\n\n* ap/clone-origin (Wed Dec 6 12:07:23 2006 +0000)\n + Explicitly add the default \"git pull\" behaviour to .git/config on clone\n\n This makes 'git clone' to mark the local 'master' to explicitly\n merge with the corresponding remote branch, which would be a\n sensible default.\n\n As discussed on the list earlier, I think it also would make\n sense to forbid 'git pull' to make a merge when:\n\n (1) branch.*.merge entries exist in $GIT_DIR/config (which\n     signals that the user is using this new mechanism), and\n (2) branch.<current-branch>.merge entry does not exist for the\n     current branch.\n\n I think it is sensible to merge to 'master' after that change.\n\n* jc/3way (Wed Nov 29 18:53:13 2006 -0800)\n + git-merge: preserve and merge local changes when doing fast forward\n\n This allows you to run a 'git merge' (or 'git pull') that\n results in a fast-forward merge that updates a path your\n working tree has modified locally; it merges your local changes\n into the updated version, in the same way the branch switching\n 'git checkout -m' works.  It has been in next for some time and\n unless we hear somebody scream I think it is Ok to merge to\n 'master'.\n \n* jc/blame-boundary (Fri Dec 1 20:45:45 2006 -0800)\n - git-blame: show lines attributed to boundary commits differently.\n\n This was discussed in a thread on grouping the short-log entries\n differently and measuring the importance of each commit.  While\n it does not break things per-se, nobody seems to want to use it\n for scripting yet, so it is staying in 'pu'.\n\n* jc/commit-careful (Tue Oct 24 21:48:55 2006 -0700)\n + git-commit: show --summary after successful commit.\n\n I think this is safe to merge to 'master'.\n\n* jc/diff (Mon Sep 25 23:03:34 2006 -0700)\n - para-walk: walk n trees, index and working tree in parallel\n\n This has been backburnered for a long time.  No time to work on\n and no immediate need to use it for scripts myself yet.\n\n* jc/diff-apply-patch (Fri Sep 22 16:17:58 2006 -0700)\n + git-diff/git-apply: make diff output a bit friendlier to GNU patch (part 2)\n\n This changes the output of \"git diff\" for a filename with\n embedded SP and requires everybody to switch to its predecessor\n commit ce74618d (which is in v1.4.4 but not in v1.4.3 series)\n which prepared for this change.  Perhaps sometime in February.\n\n* jc/explain (Mon Dec 4 19:35:04 2006 -0800)\n - git-explain\n\n This was just a discussion starter.  I tried to reuse existing\n status markers various existing command leaves, but it might be\n a good idea to invent a unified status marker to help 'git\n explain' (or 'git wtf') command, so that everybody can write\n into the same file and 'explain' has to know only about that\n file.  I dunno.\n\n* jc/fpc (Sun Nov 26 16:29:07 2006 -0800)\n - (experimental) per-topic shortlog.\n\n This was my attempt to give a different grouping of the\n short-log entries.  Will drop soon from 'pu'.\n\n* jc/leftright (Sun Oct 22 17:32:47 2006 -0700)\n - rev-list --left-right.\n\n When reviewing \"git log --merge\" I often wish which side each\n of the commits comes from, and this is to achieve that.  I\n haven't met with an enthusiastic support for it, though.\n Perhaps people do not find need for that, or do not do\n complicated merges, or have other tools that I do not regularly\n use that is better than this approach; in which case I should\n probably drop this.\n\n* jc/pickaxe (Sun Nov 5 11:52:43 2006 -0800)\n - blame: --show-stats for easier optimization work.\n\n* jc/read-tree-ignore (Tue Dec 5 23:44:23 2006 -0800)\n + read-tree: document --exclude-per-directory\n + Loosen \"working file will be lost\" check in Porcelain-ish\n + read-tree: further loosen \"working file will be lost\" check.\n\n I think this is a 'master' material modulo bugs.  Will cook\n further in 'next'.\n\n* jc/web (Wed Nov 8 14:54:09 2006 -0800)\n - gitweb: steal loadavg throttle from kernel.org\n\n* js/merge (Wed Dec 6 16:45:42 2006 +0100)\n + merge-file: support -p and -q; fix compile warnings\n + Add builtin merge-file, a minimal replacement for RCS merge\n + xdl_merge(): fix and simplify conflict handling\n + xdl_merge(): fix thinko\n + xdl_merge(): fix an off-by-one bug\n + merge-recursive: use xdl_merge().\n + xmerge: make return value from xdl_merge() more usable.\n + xdiff: add xdl_merge()\n\n merge-recursive that does not rely on RCS \"merge\".  I use this\n exclusively these days.  Perhaps cook a little further and\n merge to 'master'.\n\n* js/shallow (Fri Nov 24 16:00:13 2006 +0100)\n + fetch-pack: Do not fetch tags for shallow clones.\n + get_shallow_commits: Avoid memory leak if a commit has been reached already.\n + git-fetch: Reset shallow_depth before auto-following tags.\n + upload-pack: Check for NOT_SHALLOW flag before sending a shallow to the client.\n + fetch-pack: Properly remove the shallow file when it becomes empty.\n + shallow clone: unparse and reparse an unshallowed commit\n + Why didn't we mark want_obj as ~UNINTERESTING in the old code?\n + Why does it mean we do not have to register shallow if we have one?\n + We should make sure that the protocol is still extensible.\n + add tests for shallow stuff\n + Shallow clone: do not ignore shallowness when following tags\n + allow deepening of a shallow repository\n + allow cloning a repository \"shallowly\"\n + support fetching into a shallow repository\n + upload-pack: no longer call rev-list\n\n The shallow clone.  I do not use it myself but it does not seem\n to break the system for users that do not use shallow\n repositories.  Probably with a better documentation of its\n limitations and caveats, this should be mergeable to 'master'.\n\n* lh/branch-rename (Thu Nov 30 03:16:56 2006 +0100)\n + git-branch: let caller specify logmsg\n + rename_ref: use lstat(2) when testing for symlink\n + git-branch: add options and tests for branch renaming\n\n I do not rename branches myself and do not see a need for this\n nor I have tested it in real-world setting.  The code seemed\n clean and may be 'master' material.\n\n* np/addcommit (Mon Dec 4 11:13:39 2006 -0500)\n + make 'git add' a first class user friendly interface to the index\n\n* sv/git-svn (Tue Dec 5 16:17:38 2006 +1100)\n - git-svn: re-map repository URLs and UUIDs on SVK mirror paths\n - git-svn: collect revision properties when fetching\n - git-svn: collect SVK source URL on mirror paths\n - git-svn: let libsvn_ls_fullurl return properties too\n - git-svn: make test for SVK mirror path import\n\n Eric already commented on them but no progress since then.\n Parked in 'pu' only for discussion and these will be replaced\n when resubmitted.\n\n\n[Footnote]\n\n*1* I am trying out an alternative to short-log.  I think the\nabove format is easier to see what is going on than separate\nshort-log for 'next' and 'pu'.  It is based on the \"TO\" script\nfound in 'todo' branch but hand edited.\n\n"},{"id":"295095","messageId":"el7dsn$9a6$1@sea.gmane.org","threadId":"43469","inReplyTo":"7vvekoyb79.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-12-06T21:51:13Z","receivedAt":"2006-12-06T21:51:13Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Here is a list of topics that are cooking; the commits marked\n> with '+' are in 'next', '-' are in 'pu'.  Dates are when the\n> topic was last touched [*1*].\n> \n> ----------------------------------------------------------------\n\n> * jc/3way (Wed Nov 29 18:53:13 2006 -0800)\n>  + git-merge: preserve and merge local changes when doing fast forward\n> \n>  This allows you to run a 'git merge' (or 'git pull') that\n>  results in a fast-forward merge that updates a path your\n>  working tree has modified locally; it merges your local changes\n>  into the updated version, in the same way the branch switching\n>  'git checkout -m' works.  It has been in next for some time and\n>  unless we hear somebody scream I think it is Ok to merge to\n>  'master'.\n\nVery nice. Less suprises for CVS users (with \"update then commit\"\nmentality/habits).\n  \n> * jc/explain (Mon Dec 4 19:35:04 2006 -0800)\n>  - git-explain\n> \n>  This was just a discussion starter.  I tried to reuse existing\n>  status markers various existing command leaves, but it might be\n>  a good idea to invent a unified status marker to help 'git\n>  explain' (or 'git wtf') command, so that everybody can write\n>  into the same file and 'explain' has to know only about that\n>  file.  I dunno.\n\nI think it would be nice to have... but as it is very fresh\nit probably should cook for a while in next.\n \n> * jc/leftright (Sun Oct 22 17:32:47 2006 -0700)\n>  - rev-list --left-right.\n> \n>  When reviewing \"git log --merge\" I often wish which side each\n>  of the commits comes from, and this is to achieve that.  I\n>  haven't met with an enthusiastic support for it, though.\n>  Perhaps people do not find need for that, or do not do\n>  complicated merges, or have other tools that I do not regularly\n>  use that is better than this approach; in which case I should\n>  probably drop this.\n\nLooks nice, as an alternative to git-cherry-pick (which sometimes\ndoesn't do - because it cannot - it's work).\n \n> * jc/web (Wed Nov 8 14:54:09 2006 -0800)\n>  - gitweb: steal loadavg throttle from kernel.org\n\nIs having loadavg in gitweb, and not configured in server good idea?\nWhat next, log generation in gitweb? Just kidding.\n \n> * js/merge (Wed Dec 6 16:45:42 2006 +0100)\n>  + merge-file: support -p and -q; fix compile warnings\n>  + Add builtin merge-file, a minimal replacement for RCS merge\n>  + xdl_merge(): fix and simplify conflict handling\n>  + xdl_merge(): fix thinko\n>  + xdl_merge(): fix an off-by-one bug\n>  + merge-recursive: use xdl_merge().\n>  + xmerge: make return value from xdl_merge() more usable.\n>  + xdiff: add xdl_merge()\n> \n>  merge-recursive that does not rely on RCS \"merge\".  I use this\n>  exclusively these days.  Perhaps cook a little further and\n>  merge to 'master'.\n\nVery nice, especially with zealous (tight) merge conflicts.\n\n> * lh/branch-rename (Thu Nov 30 03:16:56 2006 +0100)\n>  + git-branch: let caller specify logmsg\n>  + rename_ref: use lstat(2) when testing for symlink\n>  + git-branch: add options and tests for branch renaming\n> \n>  I do not rename branches myself and do not see a need for this\n>  nor I have tested it in real-world setting.  The code seemed\n>  clean and may be 'master' material.\n\nI'd like to have this, but it MUST work well with reflogs for me.\n \n> [Footnote]\n> \n> *1* I am trying out an alternative to short-log.  I think the\n> above format is easier to see what is going on than separate\n> short-log for 'next' and 'pu'.  It is based on the \"TO\" script\n> found in 'todo' branch but hand edited.\n\nIt looks and reads better. I usually read only description,\nas shortlog is not that useful unless you are interested in\ngiven topic. At least for me.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297648","messageId":"7vmz60y8mw.fsf@assigned-by-dhcp.cox.net","threadId":"43469","inReplyTo":"el7dsn$9a6$1@sea.gmane.org","subject":"Re: What's cooking in git.git (topics)","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-06T22:14:31Z","receivedAt":"2006-12-06T22:14:31Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski <jnareb@gmail.com> writes:\n\n>> * jc/3way (Wed Nov 29 18:53:13 2006 -0800)\n>>  + git-merge: preserve and merge local changes when doing fast forward\n>> \n>>  This allows you to run a 'git merge' (or 'git pull') that\n>>  results in a fast-forward merge that updates a path your\n>>  working tree has modified locally; it merges your local changes\n>>  into the updated version, in the same way the branch switching\n>>  'git checkout -m' works.  It has been in next for some time and\n>>  unless we hear somebody scream I think it is Ok to merge to\n>>  'master'.\n>\n> Very nice. Less suprises for CVS users (with \"update then commit\"\n> mentality/habits).\n\nThis only makes \"update; edit; update; commit\" to work.  \"edit;\ncommit; edit; commit; edit; update; commit\" would not work,\nbecause you would be faced to resolving the conflicts upon the\nlast update while your working tree is already contaminated with\nyour own changes (it can be done and experienced people have\ndone so, but you are talking about \"CVS users\" here).\n\nWe'd be much better off to encourage users to shake \"update then\ncommit\" habit, especially if they are on a slow link.\n\n>> * jc/web (Wed Nov 8 14:54:09 2006 -0800)\n>>  - gitweb: steal loadavg throttle from kernel.org\n>\n> Is having loadavg in gitweb, and not configured in server good idea?\n\nHave you looked at the code to see what it does?\n\n>> * lh/branch-rename (Thu Nov 30 03:16:56 2006 +0100)\n>>  + git-branch: let caller specify logmsg\n>>  + rename_ref: use lstat(2) when testing for symlink\n>>  + git-branch: add options and tests for branch renaming\n>> \n>>  I do not rename branches myself and do not see a need for this\n>>  nor I have tested it in real-world setting.  The code seemed\n>>  clean and may be 'master' material.\n>\n> I'd like to have this, but it MUST work well with reflogs for me.\n\nThen test it and fix breakage if any please.\n"},{"id":"298351","messageId":"Pine.LNX.4.63.0612070035570.28348@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43469","inReplyTo":"7vvekoyb79.fsf@assigned-by-dhcp.cox.net","subject":"Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-06T23:42:42Z","receivedAt":"2006-12-06T23:42:42Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 6 Dec 2006, Junio C Hamano wrote:\n\n> Here is a list of topics that are cooking; the commits marked\n> with '+' are in 'next', '-' are in 'pu'.  Dates are when the\n> topic was last touched [*1*].\n\nI like the combined pu/next \"What's new\".\n\n> * ap/clone-origin (Wed Dec 6 12:07:23 2006 +0000)\n> [...]\n>  I think it is sensible to merge to 'master' after that change.\n\nMe, too. I really would like this to go in.\n\n> * jc/3way (Wed Nov 29 18:53:13 2006 -0800)\n>  + git-merge: preserve and merge local changes when doing fast forward\n> [...]\n>  It has been in next for some time and unless we hear somebody scream I \n>  think it is Ok to merge to 'master'.\n\nThis is something I am looking forward to to test. Maybe in \"next\" for \nwhile before putting it into \"master\"?\n\n> * jc/explain (Mon Dec 4 19:35:04 2006 -0800)\n>  - git-explain\n\nI vote for putting this into \"next\" for a wider audience. It also would \nhelp people to submit patches (it is kind of a hassle to branch \"pu\", so I \nrarely do it myself, whereas my git is based on \"next\" at all times).\n\n> * js/merge (Wed Dec 6 16:45:42 2006 +0100)\n>\n>  merge-recursive that does not rely on RCS \"merge\".  I use this\n>  exclusively these days.  Perhaps cook a little further and\n>  merge to 'master'.\n\nYes, definitely cook it for at least a week; maybe I find the time to \ncheck the conflicted merges in git.git at least.\n\n> * js/shallow (Fri Nov 24 16:00:13 2006 +0100)\n> \n>  Probably with a better documentation of its limitations and caveats, \n>  this should be mergeable to 'master'.\n\nThe more I see the missing reaction, the less sure I am this is a sensible \nthing to do.\n\nAnd it would need more safety valves, not just documentation. For example, \nI am not sure if a push from/to a shalow repo is safe.\n\nCiao,\nDscho\n"},{"id":"298453","messageId":"87zma06ptm.fsf@wine.dyndns.org","threadId":"43469","inReplyTo":"Pine.LNX.4.63.0612070035570.28348@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: What's cooking in git.git (topics)","fromName":"Alexandre Julliard","fromEmail":"julliard@winehq.org","sentAt":"2006-12-07T09:03:01Z","receivedAt":"2006-12-07T09:03:01Z","isPatch":false,"sender":{"key":"julliard@winehq.org","avatar":null},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n>> * js/shallow (Fri Nov 24 16:00:13 2006 +0100)\n>> \n>>  Probably with a better documentation of its limitations and caveats, \n>>  this should be mergeable to 'master'.\n>\n> The more I see the missing reaction, the less sure I am this is a sensible \n> thing to do.\n\nI'm not sure what reaction you expect, but this is something a lot of\nour occasional Wine users are requesting. The Wine full history is\n80Mb, and that's a big download if you just want to try a quick\npatch. Now of course you won't see these users around here hacking on\nshallow clone, most likely they just went and downloaded Wine from the\nCVS mirror instead. But it's a shame to have to maintain a CVS mirror\njust for that purpose...\n\n-- \nAlexandre Julliard\n"},{"id":"296018","messageId":"Pine.LNX.4.63.0612071557580.28348@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"43469","inReplyTo":"87zma06ptm.fsf@wine.dyndns.org","subject":"shallow clones, was Re: What's cooking in git.git (topics)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-07T14:59:39Z","receivedAt":"2006-12-07T14:59:39Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 7 Dec 2006, Alexandre Julliard wrote:\n\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n> \n> >> * js/shallow (Fri Nov 24 16:00:13 2006 +0100)\n> >> \n> >>  Probably with a better documentation of its limitations and caveats, \n> >>  this should be mergeable to 'master'.\n> >\n> > The more I see the missing reaction, the less sure I am this is a sensible \n> > thing to do.\n> \n> I'm not sure what reaction you expect, but this is something a lot of \n> our occasional Wine users are requesting. The Wine full history is 80Mb, \n> and that's a big download if you just want to try a quick patch. Now of \n> course you won't see these users around here hacking on shallow clone, \n> most likely they just went and downloaded Wine from the CVS mirror \n> instead. But it's a shame to have to maintain a CVS mirror just for that \n> purpose...\n\nSorry, I was just mumbling about the fact that I would _like_ to hear back \nabout successes and failures. If there are problems I want to fix them.\n\nSo, do you actually know of people who _used_ (as opposed to \"tested\") \nshallow clones?\n\nCiao,\nDscho\n"},{"id":"297862","messageId":"874ps77j0h.fsf@wine.dyndns.org","threadId":"43469","inReplyTo":"Pine.LNX.4.63.0612071557580.28348@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: shallow clones, was Re: What's cooking in git.git (topics)","fromName":"Alexandre Julliard","fromEmail":"julliard@winehq.org","sentAt":"2006-12-07T16:44:46Z","receivedAt":"2006-12-07T16:44:46Z","isPatch":false,"sender":{"key":"julliard@winehq.org","avatar":null},"body":"Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:\n\n> Sorry, I was just mumbling about the fact that I would _like_ to hear back \n> about successes and failures. If there are problems I want to fix them.\n>\n> So, do you actually know of people who _used_ (as opposed to \"tested\") \n> shallow clones?\n\nNo, I'm afraid not. Unfortunately, using it requires an upgraded\nserver, and I'm reluctant to put an experimental release on the main\nWine server, so I was kind of waiting for it to graduate to master. Of\ncourse that's a bit of a chicken and egg problem...\n\n-- \nAlexandre Julliard\n"},{"id":"295768","messageId":"200612071749.17849.andyparkins@gmail.com","threadId":"43469","inReplyTo":"Pine.LNX.4.63.0612070035570.28348@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: What's cooking in git.git (topics)","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-12-07T17:49:15Z","receivedAt":"2006-12-07T17:49:15Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2006, December 06 23:42, Johannes Schindelin wrote:\n\n> > * js/shallow (Fri Nov 24 16:00:13 2006 +0100)\n> >\n> >  Probably with a better documentation of its limitations and caveats,\n> >  this should be mergeable to 'master'.\n>\n> The more I see the missing reaction, the less sure I am this is a sensible\n> thing to do.\n\nDon't be too downhearted.  I am certainly looking forward to using shallow \nclones; but by their very nature they are going to be used on big established \nprojects (otherwise why would one need a shallow clone?), so until those \nprojects upgrade their servers the news will be quiet\n\nAlso; it's probably going to be casual developers that find shallow clones \nuseful, as the main developers will clone the whole repository.  This might \nalso mean that they aren't going to be around on the git mailing list.\n\nI certainly wouldn't say that the shallow clone work is not being appreciated.  \nIt's just being appreciated quietly.\n\n\nAndy\n\n\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\n"},{"id":"295266","messageId":"45793AA8.8010704@gmail.com","threadId":"43469","inReplyTo":"Pine.LNX.4.63.0612071557580.28348@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: shallow clones, was Re: What's cooking in git.git (topics)","fromName":"Aneesh Kumar K.V","fromEmail":"aneesh.kumar@gmail.com","sentAt":"2006-12-08T10:12:56Z","receivedAt":"2006-12-08T10:12:56Z","isPatch":false,"sender":{"key":"aneesh.kumar@gmail.com","avatar":"https://gravatar.com/avatar/0621fc0b2f14ead1e9024382f16053a808c148596da30c1b92572fa075621f68?d=mp&s=160"},"body":"Johannes Schindelin wrote:\n>.\n>> I'm not sure what reaction you expect, but this is something a lot of \n>> our occasional Wine users are requesting. The Wine full history is 80Mb, \n>> and that's a big download if you just want to try a quick patch. Now of \n>> course you won't see these users around here hacking on shallow clone, \n>> most likely they just went and downloaded Wine from the CVS mirror \n>> instead. But it's a shame to have to maintain a CVS mirror just for that \n>> purpose...\n> \n> Sorry, I was just mumbling about the fact that I would _like_ to hear back \n> about successes and failures. If there are problems I want to fix them.\n> \n>>\n\n\nHow about this. This is already reported \n\nkvaneesh@kvaneesh-laptop:/tmp$git clone --depth 2 /home/opensource/git git.test\n.....\n 100% (743/743) done\n\n\nkvaneesh@kvaneesh-laptop:/tmp$cd git.test/\n[master@git.test]$ git fsck-objects\n\n\n\n[master@git.test]$ git fetch --depth 4\nremote: Generating pack...\nremote: Done counting 872 objects.\n...\n 100% (1/1) done\nTotal 1 (delta 0), reused 0 (delta 0)\nUnpacking 1 objects\n 100% (1/1) done\n\n\n[master@git.test]$ git fsck-objects\ndangling commit aca085e577688108a2480b96a2f7077424a74e4d\ndangling commit b360cca0b100e14abffa4cae78521b493c783738\ndangling commit cd976f5c52694acb4b23c3f2425ed4f0a47ec799\n"}]}