Re: Dealing with many many git repos in a /home directory

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Alex Riesen <raa.lkml <at> gmail.com> writes:

> 
> On Thu, Feb 4, 2010 at 09:29, demerphq <demerphq <at> gmail.com> wrote:
> > Would i be correct in thinking that if i have to repos with an
> > equivalent  .git/objects/../..... file in them that the files are
> > necessarily identical and one can be replaced by a hardlink to the
> > other?
> 
> Yes, but you probably wont save as much as you'd like: think about the
> users
> who *do* repack their repositories. The .pack files will be all
> different.
> 


Maybe you can:

for each repo
  clone it to some place
  pack it with gc --aggressive
  take the resulting pack and move it (and the associated index) somewhere
  make in the same place a file with the same hash as the pack and extension
    keep and possibly, inside, some note about its content (e.q. what repo
    was cloned and at what state/time it was so frozen).
  ask the users to go in the .git/objects/packs dir of their private copy
    of the corresponding repo and hardlink there the .pack, .idx, .keep
    file that you have prepared
  ask the users to invoke git gc

Before actually doing that on something important, maybe wait have the
confirmation from some developer that there is not something flawed in the
approach.

Personally, I tend to use keep files a lot because I need to keep two
machines synchronized using "unison". Without keep files, large packs are
changed at every gc and the synchronization takes ages. By "freezing" a
stable subset of my objects I maintain the changing packs much smaller and
reduce the amount of data that needs to be carried over by unison to keep
the two machines in sync.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]