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

repack behaves unexpectedly if called in a bare _subrepo_

From
Alex Riesen <raa.lkml@gmail.com>
Date
Jun 17, 2007, 15:38 UTC
Message-ID
<20070617153810.GB2763@steel.home>

Just a heads-up. This took me by surprise. And I suppose it will be the same even if the subrepo is a real subproject.

To illustrate:
(
    mkdir super && cd super
    git init
    echo 0 > a; git add a; git commit -m0
    echo 2 >> a; git commit -a -m1
    echo 3 >> a; git commit -a -m2
    cp -a .git sub
    cd sub
    git --bare config --bool core.bare true
    git repack -a -d
)

Unexpectedly, the "super" repo is repacked, even though repack is called from the "sub". To actually repack the repo in the current directory if it is bare, use "git --bare repack ...".

This kind of makes core.bare pointless: can't rely on it anyway.
Next: Junio C Hamano
Message 1 of 3 in “repack behaves unexpectedly if called in a bare _subrepo_”
  1. Alex RiesenJun 17, 2007
  2. Junio C HamanoJun 17, 2007
  3. Alex RiesenJun 17, 2007

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.