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

Re: [PATCH/RFC] Teach repack to optionally retain otherwise lost objects

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Nov 29, 2007, 11:57 UTC
Message-ID
<Pine.LNX.4.64.0711291146090.27959@racer.site>
In-Reply-To
<7vaboxy3va.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 28 Nov 2007, Junio C Hamano wrote:
Show 10 quoted lines
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > 	Besides, a completely different idea just struck me: before
> > 	repacking, .git/objects/pack/* could be _hard linked_ to the
> > 	forkee's object stores.  Then nothing in git-repack's code
> > 	needs to be changed.
> >
> > 	Oh, well.  I just wasted 1.5 hours.
> 
> Your 1.5 hours was spent wisely to come up with that idea ;-).
Thanks ;-)
Show 8 quoted lines
> To make sure I understand your idea correctly, the procedure to repack a 
> repository in a fork-friendly way is:
> 
>  (1) find the project directly forked from you;
> 
>  (2) hardlink all packs under your object store to their object store;
> 
>  (3) repack -a -l and prune.
Yep.
> I think that would work as long as you do the above as a unit and handle
> one repository at a time.
Exactly.  See
http://repo.or.cz/w/repo.git?a=commitdiff;h=fba501deabd349afbe3b8bf89f385889889e04ac
for a tired proposal.

Note that "prune" is not (yet) an option, since it could possibly destroy objects which are needed in an ongoing push operation.

However, we could do exactly the same as with reflogs: introduce a grace period (with loose objects, we can use the ctime...)

> Otherwise I think you risk losing necessary objects when hierarchical 
> forks are involved.  E.g.  if you have a project X that has a fork Y 
> which in turn has fork Z.

Well, in theory you could also iterate over all projects and hard link the packs/objects of their alternates, and _then_ iterate and repack. But it is simpler and more obvious in the case of repo.or.cz to do all in one iteration, because we can order the repository names easily so that forkees come first, _and_ we have an easy way to find out what are the forks of a project.

Ciao, Dscho

Previous: Junio C HamanoNext: Johannes Schindelin
Message 7 of 14 in “[RFC] Alternates and broken repos: A pack and prune scheme to avoid them”
  1. Johannes SixtNov 18, 2007
  2. Junio C HamanoNov 18, 2007
  3. Johannes SixtNov 18, 2007
  4. Junio C HamanoNov 18, 2007
  5. Teach repack to optionally retain otherwise lost objectsJohannes Schindelin, Nov 29, 2007
  6. Junio C HamanoNov 29, 2007
  7. Johannes SchindelinNov 29, 2007
  8. Add "--expire <time>" option to 'git prune'Johannes Schindelin, Nov 29, 2007
  9. Johannes SixtNov 29, 2007
  10. Add "--expire <time>" option to 'git prune'Johannes Schindelin, Nov 29, 2007
  11. Jeff KingNov 29, 2007
  12. Johannes SchindelinNov 29, 2007
  13. Junio C HamanoNov 29, 2007
  14. Add "--expire <time>" option to 'git prune'Johannes Schindelin, Nov 29, 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.