A local shared clone is now much slower
Hi guys, So commit 0433ad128c59 (clone: run check_everything_connected) (which turned up with v1.8.3) added a large traversal to clone which (as the comment said) makes a clone much slower. It is especially noticeable on git clone -s -l -n which I use every day and used to be almost instant. Is there any thought to making it fast again, please? The above clone is very useful for working with different branches in one tree without touching every file in the main branch you are working with (and consequent issues with rebuilding at least). As linux-next maintainer, you can imagine that I do this a bit. I am sure one of Linus' points about branches was that being able to make a fast local clone of a tree to use more than one branch was a feature. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpA3zkp3VAx8.pgp Description: PGP signature
Re: A local shared clone is now much slower
Hi Duy, On Mon, 8 Jul 2013 10:20:22 +0700 Duy Nguyen pclo...@gmail.com wrote: On Mon, Jul 8, 2013 at 10:03 AM, Stephen Rothwell s...@canb.auug.org.au wrote: So commit 0433ad128c59 (clone: run check_everything_connected) (which turned up with v1.8.3) added a large traversal to clone which (as the comment said) makes a clone much slower. It is especially noticeable on git clone -s -l -n which I use every day and used to be almost instant. Is there any thought to making it fast again, please? It's done that way as a security measure against repo corruption. Although I wonder if we could do connectivity check in background instead (reports are stored in .git and picked up by git-status). The same mechanism could be used for git gc --auto. If the repo turns out corrupted, the user may lose the last ~10 minutes of work, not really bad for the speed trade off. This mode is not the default, of course. The user has to be aware of the risk when choosing this route. Thanks for the explanation. Now, is there some way I can turn it off just for the local shared case. In my case, I check my repo regularly, so don't need or want this going on while I am working ... -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpK5FEJKmn52.pgp Description: PGP signature
bug in git-fsck-cache?
Hi all, I have a tree that is a copy of Linus' git kernel tree in which I have been doing development and pulling updates and rebasing my patches etc. It now does this: $ git fsck-cache dangling tree 34d23b379f39922dff3cee671e28d41f3be56167 dangling blob 3eab2290b12a2cb683e4eadc20253bde37c84859 dangling blob 578e30193b7b67b71da1bdf0e822b8d783d8c245 dangling blob 7798f01f77b4aeacfd14586e9847deee1bf7ca74 dangling blob 81e94f8aa84684862edacb2fafff9cf9dca6878d dangling blob 85420bb37d581bc725d07c34254e4a3a1a834038 dangling tree 908ef958d87158278502966ed4f941478e18c5d7 dangling blob 93c437a0911b9d00d4ce76be30686144e8063f5e dangling tree 9c14b3618c3977e7ea58d25632585543e56f5e09 dangling tree b8c7a5af99058a82dab51eb7b27ad81987ffa5df dangling tree c004aeb8be7b0520174174e574d2655a610844a8 dangling commit c594adad5653491813959277fb87a2fef54c4e05 dangling blob d0960a82708cad4196c2d44f0a16cb3e80f77c00 dangling tree ed4e5baf7854719c19177988eb864b9be5867fa7 dangling tree ede09c2983717a0ad040e9c79f37dcb801fe49b6 dangling tree f0f3c408b22634fbd5c6409610c566ae7c92ddc3 $ git prune $ git fsck-cache dangling tree 34d23b379f39922dff3cee671e28d41f3be56167 dangling blob 3eab2290b12a2cb683e4eadc20253bde37c84859 dangling blob 578e30193b7b67b71da1bdf0e822b8d783d8c245 dangling blob 7798f01f77b4aeacfd14586e9847deee1bf7ca74 dangling blob 81e94f8aa84684862edacb2fafff9cf9dca6878d dangling blob 85420bb37d581bc725d07c34254e4a3a1a834038 dangling tree 908ef958d87158278502966ed4f941478e18c5d7 dangling blob 93c437a0911b9d00d4ce76be30686144e8063f5e dangling tree 9c14b3618c3977e7ea58d25632585543e56f5e09 dangling tree b8c7a5af99058a82dab51eb7b27ad81987ffa5df dangling tree c004aeb8be7b0520174174e574d2655a610844a8 dangling commit c594adad5653491813959277fb87a2fef54c4e05 dangling blob d0960a82708cad4196c2d44f0a16cb3e80f77c00 dangling tree ed4e5baf7854719c19177988eb864b9be5867fa7 dangling tree ede09c2983717a0ad040e9c79f37dcb801fe49b6 dangling tree f0f3c408b22634fbd5c6409610c566ae7c92ddc3 $ The commit c594adad5653491813959277fb87a2fef54c4e05 is shown as connected (in Linus' tree, not one of my patches) by gitk, so I am happy that git prune did not get rid of it, but why does fsck-cache report it as dangling? Even stranger, I actually pull Linus' tree into another tree that I have never otherwise modified and I pull updates to my work tree from it. fsck-cache finds not problems in the pristine tree. Cheers, Stephen Rothwell - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bug in git-fsck-cache?
On Wed, 31 Aug 2005 13:13:56 -0700 Junio C Hamano [EMAIL PROTECTED] wrote: Stephen Rothwell [EMAIL PROTECTED] writes: The commit c594adad5653491813959277fb87a2fef54c4e05 is shown as connected (in Linus' tree, not one of my patches) by gitk, so I am happy that git prune did not get rid of it, but why does fsck-cache report it as dangling? Hmph. You ran fsck-cache by hand without --full (i.e. you told it not to worry about objects already in packs); 'git prune' runs it with '--full' to do the full connectivity analysis. I think that's where the difference comes from. ok, with '--full' nothing gets reported as dangling. That commit is not in a pack, but is in an object directory referenced through objects/info/alternates. Is that commit reachable from any of the refs hanging under your $GIT_DIR/refs/? For example, do you have the Linus tip of the master branch in $GIT_DIR/refs/heads/origin? yes, master == origin and that commit is reachable from master according to gitk. If an object is already in a pack and later became unreachable from any of your refs, there is no way to remove that object from the pack, so dangling commits in a pack will be left dangling even after 'git prune'. It is still reachable as fsck-cache --full shows (I guess). Cheers, Stephen Rothwell - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
git merges of tags
Hi all,
Just a reminder that if you are merging Linus' tree (or any tree
really) via a tag, git was changed some time ago so that merging a tag
will not do a fast forward (there is a good reason for this - I just
can't recall it ATM). This is a problem when your current head of
branch has been merged into (e.g.) Linus' tree and then you do "git
merge " on a tag that is later than the merge point. You end up
with an unnecessary merge commit rather than just fast forwarding.
To do the fast forward, try "git merge ^{}" ... (unfortunately
doing "git merge --ff " also does not do a fast forward - it also
doesn't fail, it unexpectedly just creates a merge commit :-().
--
Cheers,
Stephen Rothwell
