{"thread":{"id":"20612","subject":"How to stop sharing objects between repositories","startedAt":"2009-08-16T00:04:58Z","lastAt":"2009-08-17T07:50:12Z","messageCount":18,"participants":["Jon Jensen","Johannes Schindelin","Jeff King","Daniel Villeneuve","Junio C Hamano","Mike Galbraith"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"120753","messageId":"alpine.DEB.2.00.0908151756150.29215@nhtr.ovalna.fjrygre.arg","threadId":"20612","inReplyTo":null,"subject":"How to stop sharing objects between repositories","fromName":"Jon Jensen","fromEmail":"jon@endpoint.com","sentAt":"2009-08-16T00:04:58Z","receivedAt":"2009-08-16T00:04:58Z","isPatch":false,"sender":{"key":"jon@endpoint.com","avatar":"https://avatars.githubusercontent.com/u/3811?v=4"},"body":"Hello.\n\nSituation: I used \"git clone -s\" to share objects between repositories. \nThat creates .git/objects/info/alternates, which points to the other \nrepository. Later I need to remove the dependency and make the dependent \nrepository self-sufficient, i.e. it should have all the objects internal \nto itself.\n\nI've looked around for a way to do that but haven't found either tools or \ninstructions.\n\nI came up with this manual way, copying over the unique remote objects and \nthen removing the alternate repository pointer:\n\n(cd /path/to/alternate/repo.git/objects && tar cp .) | (cd .git/objects && tar xvpk)\n# some objects will already exist and be skipped, leading to an error on exit, which is fine\nrm .git/objects/info/alternates\n# or if there's more than one and you're only removing one, edit the alternates file and remove only that pointer\n\n(With GNU tar -C the copy is a little simpler.)\n\nI posted this to the wiki:\n\nhttp://git.or.cz/gitwiki/GitFaq#Howtostopsharingobjectsbetweenrepositories.3F\n\nIf there's a better or built-in way to do this with Git tools, I'd like to \nlearn it, and I'd be happy to update the wiki accordingly.\n\nThanks,\nJon\n\n-- \nJon Jensen\nEnd Point Corporation\nhttp://www.endpoint.com/\n"},{"id":"120760","messageId":"alpine.DEB.1.00.0908161042210.8306@pacific.mpi-cbg.de","threadId":"20612","inReplyTo":"alpine.DEB.2.00.0908151756150.29215@nhtr.ovalna.fjrygre.arg","subject":"Re: How to stop sharing objects between repositories","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-08-16T08:43:11Z","receivedAt":"2009-08-16T08:43:11Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 15 Aug 2009, Jon Jensen wrote:\n\n> If there's a better or built-in way to do this with Git tools, I'd like \n> to learn it, and I'd be happy to update the wiki accordingly.\n\nI think what you need is done by\n\n\tgit repack -l\n\n(I agree it is not well documented, and I'd welcome a documentation \npatch.)\n\nCiao,\nDscho\n"},{"id":"120763","messageId":"20090816122842.GA942@sigill.intra.peff.net","threadId":"20612","inReplyTo":"alpine.DEB.1.00.0908161042210.8306@pacific.mpi-cbg.de","subject":"Re: How to stop sharing objects between repositories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-16T12:28:43Z","receivedAt":"2009-08-16T12:28:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Aug 16, 2009 at 10:43:11AM +0200, Johannes Schindelin wrote:\n\n> > If there's a better or built-in way to do this with Git tools, I'd like \n> > to learn it, and I'd be happy to update the wiki accordingly.\n> \n> I think what you need is done by\n> \n> \tgit repack -l\n> \n> (I agree it is not well documented, and I'd welcome a documentation \n> patch.)\n\nI think it is the opposite; packing _without_ \"-l\" will create a pack\nwith objects from the alternate; using \"-l\" suppresses them. Running\n\"git repack -a\" should do the trick, I believe (and you need the \"-a\" to\nensure that objects already packed in the repo are re-packed).\n\n-Peff\n"},{"id":"120764","messageId":"alpine.DEB.1.00.0908161429590.8306@pacific.mpi-cbg.de","threadId":"20612","inReplyTo":"20090816122842.GA942@sigill.intra.peff.net","subject":"Re: How to stop sharing objects between repositories","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-08-16T12:30:15Z","receivedAt":"2009-08-16T12:30:15Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 16 Aug 2009, Jeff King wrote:\n\n> On Sun, Aug 16, 2009 at 10:43:11AM +0200, Johannes Schindelin wrote:\n> \n> > > If there's a better or built-in way to do this with Git tools, I'd like \n> > > to learn it, and I'd be happy to update the wiki accordingly.\n> > \n> > I think what you need is done by\n> > \n> > \tgit repack -l\n> > \n> > (I agree it is not well documented, and I'd welcome a documentation \n> > patch.)\n> \n> I think it is the opposite; packing _without_ \"-l\" will create a pack\n> with objects from the alternate; using \"-l\" suppresses them. Running\n> \"git repack -a\" should do the trick, I believe (and you need the \"-a\" to\n> ensure that objects already packed in the repo are re-packed).\n\nHmm. I really would like a documentation patch, then.\n\nCiao,\nDscho\n"},{"id":"120765","messageId":"4A880F89.3060702@videotron.ca","threadId":"20612","inReplyTo":"alpine.DEB.1.00.0908161429590.8306@pacific.mpi-cbg.de","subject":"Re: How to stop sharing objects between repositories","fromName":"Daniel Villeneuve","fromEmail":"daniel2villeneuve@videotron.ca","sentAt":"2009-08-16T13:54:17Z","receivedAt":"2009-08-16T13:54:17Z","isPatch":false,"sender":{"key":"daniel2villeneuve@videotron.ca","avatar":null},"body":"Johannes Schindelin wrote:\n> Hmm. I really would like a documentation patch, then.\n>\n> \nAs another way to do it, I've used something along the lines from\n http://article.gmane.org/gmane.comp.version-control.git/62062\nnamely:\n\n\n\nI was not sure HEAD would be included via --all (e.g. HEAD pointing to a \ndangling commit), so I added it explicitly.\n\nThe reverse operation (enabling sharing for a standalone repository) is \ndescribed here\n \nhttp://git.or.cz/gitwiki/GitFaq#Howtoshareobjectsbetweenexistingrepositories.3F\n\n--\nDaniel\n"},{"id":"120766","messageId":"alpine.DEB.1.00.0908161556060.8306@pacific.mpi-cbg.de","threadId":"20612","inReplyTo":"4A880F89.3060702@videotron.ca","subject":"Re: How to stop sharing objects between repositories","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-08-16T13:57:02Z","receivedAt":"2009-08-16T13:57:02Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 16 Aug 2009, Daniel Villeneuve wrote:\n\n> Johannes Schindelin wrote:\n>\n> > Hmm. I really would like a documentation patch, then.\n>\n> As another way to do it, I've used something along the lines from\n> http://article.gmane.org/gmane.comp.version-control.git/62062\n\nWhat does this have to do with my comment?\n\nBesides, you are teaching general Git users how to use plumbing. That is \nasking for pain, and the pain will come back to the Git developers, not to \nyou.\n\nCiao,\nDscho\n"},{"id":"120767","messageId":"20090816135703.GA31638@coredump.intra.peff.net","threadId":"20612","inReplyTo":"alpine.DEB.1.00.0908161429590.8306@pacific.mpi-cbg.de","subject":"Re: How to stop sharing objects between repositories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-16T13:57:03Z","receivedAt":"2009-08-16T13:57:03Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Aug 16, 2009 at 02:30:15PM +0200, Johannes Schindelin wrote:\n\n> > I think it is the opposite; packing _without_ \"-l\" will create a pack\n> > with objects from the alternate; using \"-l\" suppresses them. Running\n> > \"git repack -a\" should do the trick, I believe (and you need the \"-a\" to\n> > ensure that objects already packed in the repo are re-packed).\n> \n> Hmm. I really would like a documentation patch, then.\n\nTo what? From git-repack(1):\n\n -l\n Pass the --local option to git-pack-objects. See git-pack-objects(1).\n\n>From git-pack-objects(1):\n\n --local\n This flag is similar to --incremental; instead of ignoring all\n packed objects, it only ignores objects that are packed and/or not\n in the local object store (i.e. borrowed from an alternate).\n\nSo I think the documentation is correct, but for the original poster, it\nsuffers from two problems:\n\n 1. The impact of \"-l\" in this case is a bit subtle and confusing.\n I.e., it is not an obvious \"use this flag to break the dependency\n on an alternate\", but rather \"don't use this flag so that you won't\n ignore non-local objects when packing\". In fact, you don't need to\n know about it at all\n\n 2. He has to know that \"git repack\" is the right place to look in the\n first place (_and_ he has to figure out that \"-l\" is what he cares\n about and follow the docs to git-pack-objects to find out what it\n does).\n\nSo I think the best thing is a \"by the way, here is how you break this\ndependency\" closer to where the concept of alternates is defined. I\nguess the best part would be under the \"-s\" flag of git-clone, since\nthat is presumably how such a situation was created (unless the user is\nsavvy enough to edit .git/objects/info/alternates themselves, in which\ncase I think we have to assume they know what they are doing).\n\nSo maybe something like this would be enough:\n\n-- >8 --\nSubject: [PATCH] docs: mention how to break alternates dependency\n\nA user who has created a repository dependency by using \"git\nclone -s\" does not necessarily know where to look to find\nout how to break that dependency. Let's mention it right\nunder \"-s\", where they are most likely to find it.\n\nSigned-off-by: Jeff King \n---\n Documentation/git-clone.txt | 5 +++++\n 1 files changed, 5 insertions(+), 0 deletions(-)\n\ndiff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\nindex b14de6c..87fa687 100644\n--- a/Documentation/git-clone.txt\n+++ b/Documentation/git-clone.txt\n@@ -72,6 +72,11 @@ These objects may be removed by normal git operations (such as 'git-commit')\n which automatically call `git gc --auto`. (See linkgit:git-gc[1].)\n If these objects are removed and were referenced by the cloned repository,\n then the cloned repository will become corrupt.\n++\n+To break the dependency of the cloned repository to the source\n+repository, run `git repack -a` in the cloned repository, which will\n+create a new pack in that repository with all referenced objects,\n+including those in the source repository.\n \n \n \n-- \n1.6.4.257.gb8ef\n"},{"id":"120774","messageId":"7vmy5z603d.fsf@alter.siamese.dyndns.org","threadId":"20612","inReplyTo":"20090816135703.GA31638@coredump.intra.peff.net","subject":"Re: How to stop sharing objects between repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-08-16T19:16:22Z","receivedAt":"2009-08-16T19:16:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Subject: [PATCH] docs: mention how to break alternates dependency\n>\n> A user who has created a repository dependency by using \"git\n> clone -s\" does not necessarily know where to look to find\n> out how to break that dependency. Let's mention it right\n> under \"-s\", where they are most likely to find it.\n>\n> Signed-off-by: Jeff King \n> ---\n> Documentation/git-clone.txt | 5 +++++\n> 1 files changed, 5 insertions(+), 0 deletions(-)\n>\n> diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\n> index b14de6c..87fa687 100644\n> --- a/Documentation/git-clone.txt\n> +++ b/Documentation/git-clone.txt\n> @@ -72,6 +72,11 @@ These objects may be removed by normal git operations (such as 'git-commit')\n> which automatically call `git gc --auto`. (See linkgit:git-gc[1].)\n> If these objects are removed and were referenced by the cloned repository,\n> then the cloned repository will become corrupt.\n> ++\n> +To break the dependency of the cloned repository to the source\n> +repository, run `git repack -a` in the cloned repository, which will\n> +create a new pack in that repository with all referenced objects,\n> +including those in the source repository.\n\nAfter reading this, two points come to my mind. They may or may not be\nissues.\n\n (1) Such a user does not necessarily know a casual \"git repack -a\" breaks\n the dependency, defeating the -s option s/he deliberately used in\n order to save disk space in the first place. Perhaps we can reword\n this further to kill two penguins with a single stone?\n\n\tNote that the pack resulting from running `git repack -a` in the\n\trepository cloned with the `-s` option will include objects that\n\tare borrowed from the source repository. It essentially breaks\n\tthe dependency created by cloning with the `-s` option by copying\n\tthe objects from the source repository. To keep borrowing from\n\tthe source repository to save disk space, do not use `repack -a`.\n\n We should suggest an alternative immediately after this sentence,\n e.g. \"Instead, use `repack -l`\" or something, but somebody should\n check if it is a valid/viable alternative.\n\n (2) IIRC, \"git gc --auto\" runs \"repack -A\". What is its effect with\n respect to this dependency between object stores? I suspect it would\n also break the dependency, but if so, is it a good thing? Perhaps\n should we change it to use a version that keeps the dependency\n instead?\n"},{"id":"120814","messageId":"1250475682.7155.16.camel@marge.simson.net","threadId":"20612","inReplyTo":"7vmy5z603d.fsf@alter.siamese.dyndns.org","subject":"Re: How to stop sharing objects between repositories","fromName":"Mike Galbraith","fromEmail":"efault@gmx.de","sentAt":"2009-08-17T02:21:22Z","receivedAt":"2009-08-17T02:21:22Z","isPatch":false,"sender":{"key":"efault@gmx.de","avatar":null},"body":"On Sun, 2009-08-16 at 12:16 -0700, Junio C Hamano wrote:\n> Jeff King writes:\n> \n> > Subject: [PATCH] docs: mention how to break alternates dependency\n> >\n> > A user who has created a repository dependency by using \"git\n> > clone -s\" does not necessarily know where to look to find\n> > out how to break that dependency. Let's mention it right\n> > under \"-s\", where they are most likely to find it.\n> >\n> > Signed-off-by: Jeff King \n> > ---\n> > Documentation/git-clone.txt | 5 +++++\n> > 1 files changed, 5 insertions(+), 0 deletions(-)\n> >\n> > diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\n> > index b14de6c..87fa687 100644\n> > --- a/Documentation/git-clone.txt\n> > +++ b/Documentation/git-clone.txt\n> > @@ -72,6 +72,11 @@ These objects may be removed by normal git operations (such as 'git-commit')\n> > which automatically call `git gc --auto`. (See linkgit:git-gc[1].)\n> > If these objects are removed and were referenced by the cloned repository,\n> > then the cloned repository will become corrupt.\n> > ++\n> > +To break the dependency of the cloned repository to the source\n> > +repository, run `git repack -a` in the cloned repository, which will\n> > +create a new pack in that repository with all referenced objects,\n> > +including those in the source repository.\n> \n> After reading this, two points come to my mind. They may or may not be\n> issues.\n> \n> (1) Such a user does not necessarily know a casual \"git repack -a\" breaks\n> the dependency, defeating the -s option s/he deliberately used in\n> order to save disk space in the first place. Perhaps we can reword\n> this further to kill two penguins with a single stone?\n\nPerhaps a runtime warning that you're about to break it? This user may\nnot even be the one who set the thing up, no?\n\n\t-T. Peanut Gallery\n"},{"id":"120831","messageId":"20090817061916.GA27530@coredump.intra.peff.net","threadId":"20612","inReplyTo":"7vmy5z603d.fsf@alter.siamese.dyndns.org","subject":"Re: How to stop sharing objects between repositories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-17T06:19:17Z","receivedAt":"2009-08-17T06:19:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Aug 16, 2009 at 12:16:22PM -0700, Junio C Hamano wrote:\n\n> After reading this, two points come to my mind. They may or may not be\n> issues.\n> \n> (1) Such a user does not necessarily know a casual \"git repack -a\" breaks\n> the dependency, defeating the -s option s/he deliberately used in\n> order to save disk space in the first place. Perhaps we can reword\n> this further to kill two penguins with a single stone?\n> \n> \tNote that the pack resulting from running `git repack -a` in the\n> \trepository cloned with the `-s` option will include objects that\n> \tare borrowed from the source repository. It essentially breaks\n> \tthe dependency created by cloning with the `-s` option by copying\n> \tthe objects from the source repository. To keep borrowing from\n> \tthe source repository to save disk space, do not use `repack -a`.\n\nGood point, but I don't think this wording is quite right. You can also\ncause such an inefficiency by simply running \"git repack\", if the source\nhas loose objects. In other words:\n\n 1. \"git repack -a\" is sufficient to break dependency, as it copies\n both packed and loose objects\n\n 2. \"git repack\" _may_ break the dependency, if there are no packs, as\n it copies only loose objects. It _may_ introduce inefficiency, but\n only if there are loose objects.\n\n 3. \"git repack -l\" always keeps the dependency and current efficiency.\n\n As an aside, making this list makes me realize there is no easy\n \"keep the dependency and increase efficiency\". In other words, pack\n everything that is not available otherwise, and then prune the\n remaining packs.\n\nModified patch is below.\n\n> We should suggest an alternative immediately after this sentence,\n> e.g. \"Instead, use `repack -l`\" or something, but somebody should\n> check if it is a valid/viable alternative.\n\nIt does work. From a user's perspective, I think \"-l\" would probably be\na more sane default. But I think it is off for historical reasons, and\nthese days we try to steer users towards \"git gc\", anyway, which does\nuse \"-l\" by default.\n\n-- >8 --\nSubject: [PATCH] docs: describe impact of repack on \"clone -s\"\n\nThe effects of repacking on a repository with alternates are\na bit subtle. The two main things users will want are:\n\n 1. Not to waste disk space by accidentally copying objects\n which could be shared.\n\n 2. Copying all objects explicitly to break the dependency\n on the source repo.\n\nThis patch describes both under the \"clone -s\"\ndocumentation. It makes sense to put it there rather than in\ngit-repack.txt for both cases. For (1), we are warning the\nuser who is using \"clone -s\" about what _not_ to do, so we\nneed to get their attention when reading about \"clone -s\".\nFor (2), we are telling them how git-repack can be used to\naccomplish a task, but until they know that git-repack is\nthe right tool, they have no reason to look at the repack\ndocumentation.\n\nSigned-off-by: Jeff King \n---\n\nThe extra deleted lines in the patch below are just cleaning up some\nexcess whitespace.\n\n Documentation/git-clone.txt | 12 ++++++++++--\n 1 files changed, 10 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\nindex b14de6c..b25944f 100644\n--- a/Documentation/git-clone.txt\n+++ b/Documentation/git-clone.txt\n@@ -72,8 +72,16 @@ These objects may be removed by normal git operations (such as 'git-commit')\n which automatically call `git gc --auto`. (See linkgit:git-gc[1].)\n If these objects are removed and were referenced by the cloned repository,\n then the cloned repository will become corrupt.\n-\n-\n++\n+Note that running `git repack` without the `-l` option in a repository\n+cloned with `-s` will copy objects from the source repository into a\n+pack in the cloned repository, removing the disk space savings of `clone\n+-s`. It is safe, however, to run `git gc`, which uses the `-l` option by\n+default.\n++\n+If you want to break the dependency of a repository cloned with `-s` on\n+its source repository, you can simply run `git repack -a` to copy all\n+objects from the source repository into a pack in the cloned repository.\n \n --reference ::\n \tIf the reference repository is on the local machine\n-- \n1.6.4.283.gec993\n"},{"id":"120832","messageId":"20090817063143.GB27530@coredump.intra.peff.net","threadId":"20612","inReplyTo":"7vmy5z603d.fsf@alter.siamese.dyndns.org","subject":"Re: How to stop sharing objects between repositories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-17T06:31:43Z","receivedAt":"2009-08-17T06:31:43Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Aug 16, 2009 at 12:16:22PM -0700, Junio C Hamano wrote:\n\n> (2) IIRC, \"git gc --auto\" runs \"repack -A\". What is its effect with\n> respect to this dependency between object stores? I suspect it would\n> also break the dependency, but if so, is it a good thing? Perhaps\n> should we change it to use a version that keeps the dependency\n> instead?\n\nNo, it actually runs \"repack -d -l -A\", which behaves fine. I even\ntested it to make sure.\n\nBTW, the \"gc.auto\" setting is really annoying at low levels (I set\ngc.auto to 1 for testing). For efficiency, it looks at only one\nhashed object directory, and then assumes the other 255 contain roughly\nthe same number of objects. But you get bad sampling error when you have\nfewer than 256 objects. I don't think it is worth caring about, though.\nIt doesn't seem very sane to set gc.auto to something so low.\n\n-Peff\n"},{"id":"120833","messageId":"20090817063225.GA31533@coredump.intra.peff.net","threadId":"20612","inReplyTo":"20090817061916.GA27530@coredump.intra.peff.net","subject":"Re: How to stop sharing objects between repositories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-17T06:32:25Z","receivedAt":"2009-08-17T06:32:25Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 17, 2009 at 02:19:16AM -0400, Jeff King wrote:\n\n> 1. \"git repack -a\" is sufficient to break dependency, as it copies\n> both packed and loose objects\n> \n> 2. \"git repack\" _may_ break the dependency, if there are no packs, as\n> it copies only loose objects. It _may_ introduce inefficiency, but\n> only if there are loose objects.\n> \n> 3. \"git repack -l\" always keeps the dependency and current efficiency.\n> \n> As an aside, making this list makes me realize there is no easy\n> \"keep the dependency and increase efficiency\". In other words, pack\n> everything that is not available otherwise, and then prune the\n> remaining packs.\n\nOK, I take it back. \"git repack -d -l -A\" will get rid of any packs that\nare redundant with your alternate.\n\n-Peff\n"},{"id":"299109","messageId":"20090817064801.GA31543@coredump.intra.peff.net","threadId":"20612","inReplyTo":"1250475682.7155.16.camel@marge.simson.net","subject":"Re: How to stop sharing objects between repositories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-17T06:48:02Z","receivedAt":"2009-08-17T06:48:02Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 17, 2009 at 04:21:22AM +0200, Mike Galbraith wrote:\n\n> > (1) Such a user does not necessarily know a casual \"git repack -a\" breaks\n> > the dependency, defeating the -s option s/he deliberately used in\n> > order to save disk space in the first place. Perhaps we can reword\n> > this further to kill two penguins with a single stone?\n> \n> Perhaps a runtime warning that you're about to break it? This user may\n> not even be the one who set the thing up, no?\n\nI'm not really sure what such a setup would look like. If it is a big\nhosting site like kernel.org or repo.or.cz, then probably it wouldn't\nmatter much. The admins there should probably be running \"git repack -l\n-d -A\" periodically to consolidate the object stores (which can happen\nfrom this sort of repacking, or from people just pushing the same\ncommits to their repos).\n\nThat being said, I can see there being setups where such a warning might\nbe useful. However, we don't really know if the user _wants_ that\neffect, or if it is an accident. So people following the recommnded\n\"here is how you break the dependency\" advice will also get the warning.\n\nI'm torn on whether this is actually a good idea.\n\n-- >8 --\nSubject: [PATCH] repack: warn when \"-l\" is not used with alternates\n\nFailing to use \"-l\" means that we will copy objects from the\nsource repository, nullifying the usefulness of \"-s\". We\ndon't want to make this an error, though, since \"git repack\n-a\" is used to intentionally break the dependency.\n\nSigned-off-by: Jeff King \n---\nIs \"test -s\" portable? It's in POSIX, but I have some lingering doubt in\nthe back of my mind.\n\nA user seeing such a warning can perhaps ^C to abort the pack. However,\nshould we also give instructions on how to undo the copying (which\nshould be \"git repack -d -l -A\")?\n\n git-repack.sh | 9 +++++++++\n 1 files changed, 9 insertions(+), 0 deletions(-)\n\ndiff --git a/git-repack.sh b/git-repack.sh\nindex 1eb3bca..0bdc6e9 100755\n--- a/git-repack.sh\n+++ b/git-repack.sh\n@@ -44,6 +44,15 @@ do\n \tshift\n done\n \n+if test -z \"$local\" && test -s \"$GIT_DIR/objects/info/alternates\"; then\n+cat >&2 <<'EOF'\n+warning: this repository uses objects from other repositories via the\n+warning: \"alternates\" mechanism; repacking without \"-l\" will cause objects\n+warning: to be copied into this repository, wasting disk space.\n+\n+EOF\n+fi\n+\n case \"`git config --bool repack.usedeltabaseoffset || echo true`\" in\n true)\n \textra=\"$extra --delta-base-offset\" ;;\n-- \n1.6.4.283.ga2765.dirty\n\n"},{"id":"120835","messageId":"1250493173.9178.8.camel@marge.simson.net","threadId":"20612","inReplyTo":"20090817064801.GA31543@coredump.intra.peff.net","subject":"Re: How to stop sharing objects between repositories","fromName":"Mike Galbraith","fromEmail":"efault@gmx.de","sentAt":"2009-08-17T07:12:53Z","receivedAt":"2009-08-17T07:12:53Z","isPatch":false,"sender":{"key":"efault@gmx.de","avatar":null},"body":"On Mon, 2009-08-17 at 02:48 -0400, Jeff King wrote:\n> On Mon, Aug 17, 2009 at 04:21:22AM +0200, Mike Galbraith wrote:\n> \n> > > (1) Such a user does not necessarily know a casual \"git repack -a\" breaks\n> > > the dependency, defeating the -s option s/he deliberately used in\n> > > order to save disk space in the first place. Perhaps we can reword\n> > > this further to kill two penguins with a single stone?\n> > \n> > Perhaps a runtime warning that you're about to break it? This user may\n> > not even be the one who set the thing up, no?\n> \n> I'm not really sure what such a setup would look like. If it is a big\n> hosting site like kernel.org or repo.or.cz, then probably it wouldn't\n> matter much. The admins there should probably be running \"git repack -l\n> -d -A\" periodically to consolidate the object stores (which can happen\n> from this sort of repacking, or from people just pushing the same\n> commits to their repos).\n> \n> That being said, I can see there being setups where such a warning might\n> be useful. However, we don't really know if the user _wants_ that\n> effect, or if it is an accident. So people following the recommnded\n> \"here is how you break the dependency\" advice will also get the warning.\n> \n> I'm torn on whether this is actually a good idea.\n\nYeah. There are any number of ways to shoot oneself in the foot, and\nwhile on the one hand idiot proofing can be nice if you were about to\nscrew up, \"really really?\" messages are most frequently annoying noise.\n\n\t-Mike\n"},{"id":"120837","messageId":"7v63cm3ntl.fsf@alter.siamese.dyndns.org","threadId":"20612","inReplyTo":"20090817064801.GA31543@coredump.intra.peff.net","subject":"Re: How to stop sharing objects between repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-08-17T07:24:22Z","receivedAt":"2009-08-17T07:24:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Mon, Aug 17, 2009 at 04:21:22AM +0200, Mike Galbraith wrote:\n>\n>> > (1) Such a user does not necessarily know a casual \"git repack -a\" breaks\n>> > the dependency, defeating the -s option s/he deliberately used in\n>> > order to save disk space in the first place. Perhaps we can reword\n>> > this further to kill two penguins with a single stone?\n>> \n>> Perhaps a runtime warning that you're about to break it? This user may\n>> not even be the one who set the thing up, no?\n>\n> I'm not really sure what such a setup would look like....\n> ...\n> That being said, I can see there being setups where such a warning might\n> be useful. However, we don't really know if the user _wants_ that\n> effect, or if it is an accident.\n> ...\n> \"here is how you break the dependency\" advice will also get the warning.\n>\n> I'm torn on whether this is actually a good idea.\n\nI would understand if you were torn if the proposed change were to refuse\nto run without -l in a repository with alternates when --force is not\ngiven, or something of that nature.\n\nBut I can tell you that this \"just warn\" cannot be a good idea for a very\nsimple reason: breaking and then warning is useless---it is too late for\nthe user to do anything about it.\n"},{"id":"120838","messageId":"20090817072559.GA9730@coredump.intra.peff.net","threadId":"20612","inReplyTo":"7v63cm3ntl.fsf@alter.siamese.dyndns.org","subject":"Re: How to stop sharing objects between repositories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-17T07:25:59Z","receivedAt":"2009-08-17T07:25:59Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 17, 2009 at 12:24:22AM -0700, Junio C Hamano wrote:\n\n> > I'm torn on whether this is actually a good idea.\n> \n> I would understand if you were torn if the proposed change were to refuse\n> to run without -l in a repository with alternates when --force is not\n> given, or something of that nature.\n> \n> But I can tell you that this \"just warn\" cannot be a good idea for a very\n> simple reason: breaking and then warning is useless---it is too late for\n> the user to do anything about it.\n\nDid you miss the part where I asked \"should we include instructions to\nthe user on how to fix this\"?\n\n-Peff\n"},{"id":"120839","messageId":"7v1vna3nae.fsf@alter.siamese.dyndns.org","threadId":"20612","inReplyTo":"20090817072559.GA9730@coredump.intra.peff.net","subject":"Re: How to stop sharing objects between repositories","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-08-17T07:35:53Z","receivedAt":"2009-08-17T07:35:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n>> But I can tell you that this \"just warn\" cannot be a good idea for a very\n>> simple reason: breaking and then warning is useless---it is too late for\n>> the user to do anything about it.\n>\n> Did you miss the part where I asked \"should we include instructions to\n> the user on how to fix this\"?\n\nActually, I didn't. It is very hard to lose data once you put it in git;\n\"by following recovery insn the user can redo\" is often trivially correct\nthanks to it.\n\nBut it is not a very good option to cause the damage and then give\nrecovery insn. The user might have ran out of quota, and even if he\ndidn't, he wasted needless cycles for the unwanted sort of repacking.\n"},{"id":"120840","messageId":"20090817075012.GA3437@sigill.intra.peff.net","threadId":"20612","inReplyTo":"7v1vna3nae.fsf@alter.siamese.dyndns.org","subject":"Re: How to stop sharing objects between repositories","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-08-17T07:50:12Z","receivedAt":"2009-08-17T07:50:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Aug 17, 2009 at 12:35:53AM -0700, Junio C Hamano wrote:\n\n> > Did you miss the part where I asked \"should we include instructions to\n> > the user on how to fix this\"?\n> \n> Actually, I didn't. It is very hard to lose data once you put it in git;\n> \"by following recovery insn the user can redo\" is often trivially correct\n> thanks to it.\n> \n> But it is not a very good option to cause the damage and then give\n> recovery insn. The user might have ran out of quota, and even if he\n> didn't, he wasted needless cycles for the unwanted sort of repacking.\n\nOK, let's forget the warning, then. Hopefully between the note under\n\"clone -s\" and the fact that most people should be using \"git gc\" these\ndays, it won't be a big issue.\n\n-Peff\n"}]}