{"thread":{"id":"12978","subject":"[PATCH] git-clone.txt: Adjust note to --shared for new pruning behavior of git-gc","startedAt":"2008-04-03T18:26:13Z","lastAt":"2008-04-04T14:25:53Z","messageCount":6,"participants":["Brandon Casey","Johannes Schindelin","Jakub Narebski"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"73617","messageId":"47F52145.306@nrlssc.navy.mil","threadId":"12978","inReplyTo":null,"subject":"[PATCH] git-clone.txt: Adjust note to --shared for new pruning behavior of git-gc","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-04-03T18:26:13Z","receivedAt":"2008-04-03T18:26:13Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Since git-gc now always calls prune, even with --auto, unreferenced objects\nmay be removed by more operations than just git-gc. This is important for\nclones created using --shared or --reference.\n\nSigned-off-by: Brandon Casey \n---\n Documentation/git-clone.txt | 12 ++++++++----\n 1 files changed, 8 insertions(+), 4 deletions(-)\n\ndiff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\nindex 9758243..d3ab00b 100644\n--- a/Documentation/git-clone.txt\n+++ b/Documentation/git-clone.txt\n@@ -65,10 +65,12 @@ OPTIONS\n +\n *NOTE*: this is a possibly dangerous operation; do *not* use\n it unless you understand what it does. If you clone your\n-repository using this option, then delete branches in the\n-source repository and then run linkgit:git-gc[1] using the\n-'--prune' option in the source repository, it may remove\n-objects which are referenced by the cloned repository.\n+repository using this option and then delete branches in the\n+source repository, some objects may become unreferenced (or dangling).\n+These objects may be removed by normal git operations (such as git-commit[1])\n+which automatically call git-gc[1]. If these objects are removed and\n+were referenced by the cloned repository, then the cloned repository\n+will become corrupt.\n \n \n \n@@ -79,6 +81,8 @@ objects which are referenced by the cloned repository.\n \tan already existing repository as an alternate will\n \trequire fewer objects to be copied from the repository\n \tbeing cloned, reducing network and local storage costs.\n++\n+*NOTE*: see NOTE to --shared option.\n \n --quiet::\n -q::\n-- \n1.5.5.rc3\n"},{"id":"73622","messageId":"alpine.LSU.1.00.0804032113280.4008@racer.site","threadId":"12978","inReplyTo":"47F52145.306@nrlssc.navy.mil","subject":"Re: [PATCH] git-clone.txt: Adjust note to --shared for new pruning behavior of git-gc","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-03T19:14:39Z","receivedAt":"2008-04-03T19:14:39Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 3 Apr 2008, Brandon Casey wrote:\n\n> diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\n> index 9758243..d3ab00b 100644\n> --- a/Documentation/git-clone.txt\n> +++ b/Documentation/git-clone.txt\n> @@ -65,10 +65,12 @@ OPTIONS\n> +\n> *NOTE*: this is a possibly dangerous operation; do *not* use\n> it unless you understand what it does. If you clone your\n> -repository using this option, then delete branches in the\n> -source repository and then run linkgit:git-gc[1] using the\n> -'--prune' option in the source repository, it may remove\n> -objects which are referenced by the cloned repository.\n> +repository using this option and then delete branches in the\n> +source repository, some objects may become unreferenced (or dangling).\n> +These objects may be removed by normal git operations (such as git-commit[1])\n> +which automatically call git-gc[1]. If these objects are removed and\n> +were referenced by the cloned repository, then the cloned repository\n> +will become corrupt.\n\nPlease note that if you delete a branch _after_ running git-gc, the next \ngit-gc would remove those objects anyway, since the first git-gc packed \nthe objects, and they were therefore no longer dangling.\n\nSo it was an issue before the new git-gc behaviour anyway.\n\nCiao,\nDscho\n"},{"id":"73627","messageId":"alpine.LSU.1.00.0804032200310.4008@racer.site","threadId":"12978","inReplyTo":"47F54342.1040901@nrlssc.navy.mil","subject":"Re: [PATCH] git-clone.txt: Adjust note to --shared for new pruning behavior of git-gc","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-03T20:01:48Z","receivedAt":"2008-04-03T20:01:48Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 3 Apr 2008, Brandon Casey wrote:\n\n> Johannes Schindelin wrote:\n> \n> > On Thu, 3 Apr 2008, Brandon Casey wrote:\n> > \n> >> diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\n> >> index 9758243..d3ab00b 100644\n> >> --- a/Documentation/git-clone.txt\n> >> +++ b/Documentation/git-clone.txt\n> >> @@ -65,10 +65,12 @@ OPTIONS\n> >> +\n> >> *NOTE*: this is a possibly dangerous operation; do *not* use\n> >> it unless you understand what it does. If you clone your\n> >> -repository using this option, then delete branches in the\n> >> -source repository and then run linkgit:git-gc[1] using the\n> >> -'--prune' option in the source repository, it may remove\n> >> -objects which are referenced by the cloned repository.\n> >> +repository using this option and then delete branches in the\n> >> +source repository, some objects may become unreferenced (or dangling).\n> >> +These objects may be removed by normal git operations (such as git-commit[1])\n> >> +which automatically call git-gc[1]. If these objects are removed and\n> >> +were referenced by the cloned repository, then the cloned repository\n> >> +will become corrupt.\n> > \n> > Please note that if you delete a branch _after_ running git-gc, the next \n> > git-gc would remove those objects anyway, since the first git-gc packed \n> > the objects, and they were therefore no longer dangling.\n> \n> I thought they would be retained unless --prune was used. git-gc uses the\n> -A option to repack when --prune is not used and -a when --prune is used.\n\nOh, you're right. I forgot.\n\n> But what I was really trying to point out in the documentation changes \n> was that now _other_ commands such as git-commit are also unsafe since \n> they call 'git-gc --auto' and could cause loose unreferenced objects to \n> be deleted. So it is not enough to just avoid calling git-gc when \n> dealing with a --shared repository.\n\nRight. Hmm. I missed that completely when I thought about prune \n--expire.\n\nSorry,\nDscho\n"},{"id":"73624","messageId":"47F54342.1040901@nrlssc.navy.mil","threadId":"12978","inReplyTo":"alpine.LSU.1.00.0804032113280.4008@racer.site","subject":"Re: [PATCH] git-clone.txt: Adjust note to --shared for new pruning behavior of git-gc","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-04-03T20:51:14Z","receivedAt":"2008-04-03T20:51:14Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Johannes Schindelin wrote:\n> Hi,\n> \n> On Thu, 3 Apr 2008, Brandon Casey wrote:\n> \n>> diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt\n>> index 9758243..d3ab00b 100644\n>> --- a/Documentation/git-clone.txt\n>> +++ b/Documentation/git-clone.txt\n>> @@ -65,10 +65,12 @@ OPTIONS\n>> +\n>> *NOTE*: this is a possibly dangerous operation; do *not* use\n>> it unless you understand what it does. If you clone your\n>> -repository using this option, then delete branches in the\n>> -source repository and then run linkgit:git-gc[1] using the\n>> -'--prune' option in the source repository, it may remove\n>> -objects which are referenced by the cloned repository.\n>> +repository using this option and then delete branches in the\n>> +source repository, some objects may become unreferenced (or dangling).\n>> +These objects may be removed by normal git operations (such as git-commit[1])\n>> +which automatically call git-gc[1]. If these objects are removed and\n>> +were referenced by the cloned repository, then the cloned repository\n>> +will become corrupt.\n> \n> Please note that if you delete a branch _after_ running git-gc, the next \n> git-gc would remove those objects anyway, since the first git-gc packed \n> the objects, and they were therefore no longer dangling.\n\nI thought they would be retained unless --prune was used. git-gc uses the\n-A option to repack when --prune is not used and -a when --prune is used.\n\nI think even with the new prune behavior they would still be retained as\nlong as they were packed since the prune only affects loose objects.\n\n> So it was an issue before the new git-gc behaviour anyway.\n\nWell, I thought that git-gc had become \"safe\" with respect to --shared\nrepositories ever since the call to repack started using -A when --prune\nwas not used.\n\nNow it is unsafe again. But what I was really trying to point out in the\ndocumentation changes was that now _other_ commands such as git-commit are\nalso unsafe since they call 'git-gc --auto' and could cause loose\nunreferenced objects to be deleted. So it is not enough to just avoid calling\ngit-gc when dealing with a --shared repository.\n\n-brandon\n"},{"id":"73646","messageId":"m3prt6t8sn.fsf@localhost.localdomain","threadId":"12978","inReplyTo":"alpine.LSU.1.00.0804032200310.4008@racer.site","subject":"Re: [PATCH] git-clone.txt: Adjust note to --shared for new pruning behavior of git-gc","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-04-04T06:49:10Z","receivedAt":"2008-04-04T06:49:10Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Johannes Schindelin writes:\n\n> On Thu, 3 Apr 2008, Brandon Casey wrote:\n> > But what I was really trying to point out in the documentation changes \n> > was that now _other_ commands such as git-commit are also unsafe since \n> > they call 'git-gc --auto' and could cause loose unreferenced objects to \n> > be deleted. So it is not enough to just avoid calling git-gc when \n> > dealing with a --shared repository.\n> \n> Right. Hmm. I missed that completely when I thought about prune \n> --expire.\n\nI think that if you are using repository from which other repos borrow\nobjects via alternates, it is a good idea to turn off automatic\nrepacking with \"git gc --auto\" by setting gc.auto to 0 (or, hopefully,\n\"never\" or \"false\").\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"73656","messageId":"47F63A71.2010100@nrlssc.navy.mil","threadId":"12978","inReplyTo":"m3prt6t8sn.fsf@localhost.localdomain","subject":"Re: [PATCH] git-clone.txt: Adjust note to --shared for new pruning behavior of git-gc","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-04-04T14:25:53Z","receivedAt":"2008-04-04T14:25:53Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Jakub Narebski wrote:\n> Johannes Schindelin writes:\n> \n>> On Thu, 3 Apr 2008, Brandon Casey wrote:\n>>> But what I was really trying to point out in the documentation changes \n>>> was that now _other_ commands such as git-commit are also unsafe since \n>>> they call 'git-gc --auto' and could cause loose unreferenced objects to \n>>> be deleted. So it is not enough to just avoid calling git-gc when \n>>> dealing with a --shared repository.\n>> Right. Hmm. I missed that completely when I thought about prune \n>> --expire.\n> \n> I think that if you are using repository from which other repos borrow\n> objects via alternates, it is a good idea to turn off automatic\n> repacking with \"git gc --auto\" by setting gc.auto to 0\n\nEither that or disable only the automatic pruning by setting gc.pruneexpire\nto never.\n\n> (or, hopefully, \"never\" or \"false\").\n\nI think those only work for dates and booleans respectively. gc.auto is\nparsed as an int.\n\n-brandon\n"}]}