git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] git-clone.txt: Adjust note to --shared for new pruning behavior of git-gc

From
Brandon Casey <casey@nrlssc.navy.mil>
Date
Apr 3, 2008, 20:51 UTC
Message-ID
<47F54342.1040901@nrlssc.navy.mil>
In-Reply-To
<alpine.LSU.1.00.0804032113280.4008@racer.site>
Johannes Schindelin wrote:
Show 26 quoted lines
> Hi,
> 
> On Thu, 3 Apr 2008, Brandon Casey wrote:
> 
>> diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
>> index 9758243..d3ab00b 100644
>> --- a/Documentation/git-clone.txt
>> +++ b/Documentation/git-clone.txt
>> @@ -65,10 +65,12 @@ OPTIONS
>>  +
>>  *NOTE*: this is a possibly dangerous operation; do *not* use
>>  it unless you understand what it does. If you clone your
>> -repository using this option, then delete branches in the
>> -source repository and then run linkgit:git-gc[1] using the
>> -'--prune' option in the source repository, it may remove
>> -objects which are referenced by the cloned repository.
>> +repository using this option and then delete branches in the
>> +source repository, some objects may become unreferenced (or dangling).
>> +These objects may be removed by normal git operations (such as git-commit[1])
>> +which automatically call git-gc[1]. If these objects are removed and
>> +were referenced by the cloned repository, then the cloned repository
>> +will become corrupt.
> 
> Please note that if you delete a branch _after_ running git-gc, the next 
> git-gc would remove those objects anyway, since the first git-gc packed 
> the objects, and they were therefore no longer dangling.

I thought they would be retained unless --prune was used. git-gc uses the -A option to repack when --prune is not used and -a when --prune is used.

I think even with the new prune behavior they would still be retained as long as they were packed since the prune only affects loose objects.

> So it was an issue before the new git-gc behaviour anyway.

Well, I thought that git-gc had become "safe" with respect to --shared repositories ever since the call to repack started using -A when --prune was not used.

Now it is unsafe again. But what I was really trying to point out in the documentation changes was that now _other_ commands such as git-commit are also unsafe since they call 'git-gc --auto' and could cause loose unreferenced objects to be deleted. So it is not enough to just avoid calling git-gc when dealing with a --shared repository.

-brandon
Previous: Johannes SchindelinNext: Johannes Schindelin
Message 3 of 6 in “git-clone.txt: Adjust note to --shared for new pruning behavior of git-gc”
  1. git-clone.txt: Adjust note to --shared for new pruning behavior of git-gcBrandon Casey, Apr 3, 2008
  2. Johannes SchindelinApr 3, 2008
  3. Brandon CaseyApr 3, 2008
  4. Johannes SchindelinApr 3, 2008
  5. Jakub NarebskiApr 4, 2008
  6. Brandon CaseyApr 4, 2008

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.