> From: peter <ing...@gmail.com> > When I followed your last instructions I stumbled upon a few hardlinks in > the tar-file from my original source. And, as I understood Git treats these > hardlinks as separate files. And yes, in the tar-file from Git I found a > few exact copy's for several binaries. But now all with a unique > inode-number, wheras these files in the original tar-file had the same > inode .........
OK, that explains why when you deleted a bunch of binary files, it almost exactly fixed the space consumption -- those deleted files were the "other copies" of the hardlinked files. > 1) Use pre- & post-scripts in Git to prepare the source (undo it from > hardlinks, replace them with soft ones) > 2) Look for a third party tool that does this for me > 3) Take a look at SVN or Mercurial to see if this could be more suitable > for this specific goal (although I realy would like to stick to Git !) I doubt that there's any source-control system that handles hardlinks as such. Hardlinks are very Unix-specific and considered somewhat treacherous, so there aren't a lot of situations where they're used. If you really, really want to use hardlinks in your working copies, you'll want to have a script you can run post-checkout that reconstructs the hardlinks correctly. And I suppose have a version-controlled control file that lists what sets of files are alternative links to the same underlying file. Dale -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
