Re: [git-users] Strange effect when tar-ing a cloned repository
Hi Dale, Well ehhh. I feel somewhat ashamed right now 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 . So, case closed I think. Now I now my target will still function 100% with its filesystem from Git, but several files will be present as 100% duplicates, thus using up more memory. But luckily I've got more than enough flash ! Perhaps In the near future I'm gonna try one of the following : 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 !) Many, many thanks for all your help ! Kindest regards, Peter Op woensdag 21 augustus 2013 19:44:53 UTC+2 schreef Dale Worley: From: peter ing...@gmail.com javascript: The files that I suspect are all compiled without stripping (debug symbols present in the file). When I delete all these files the size of my tar-bal from the original filesystem is nearly the same as the one made from the git checkout. Here some things to check: Produce tar files rather than tar.gz files and see if the size difference is still present. The ordering of files in a tar file might affect how efficient the compression is. Get a directory listing of both tar files (-tv) and see if they contain exactly the same files, and with exactly the same lengths. Do a tree file comparison between the files that go into the original tar and the ones that go into the new tar. 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.
Re: [git-users] Strange effect when tar-ing a cloned repository
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.
Re: [git-users] Strange effect when tar-ing a cloned repository
If you're willing to switch to soft links, many SCM tools (including git) will handle those correctly. Plus tar will save the link rather than more copies of the file. wor...@alum.mit.edu wrote: 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. -- 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.
Re: [git-users] Strange effect when tar-ing a cloned repository
Hi Paul, Yep, I already modified my filesystem to soft-links. So now all goes well with git. Peter -- 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.
[git-users] test version in the index
After making a number of changes, I decide I want to commit some of them and continue working on the rest. I do this by moving the desired parts to the index. Before committing, it would useful if there were a way to test this commit alone, say, so it doesn't break a build. Is there a convenient way to do so? -- 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.
Re: [git-users] Can Git run for commercial purposes?
On Thu, Aug 22, 2013 at 09:23:10PM -0700, manhapt vn wrote: My company is an software outsourcing company. We're managing documents/source codes of all projects using SVN. Git is great and truly fast. I really like it. Yes, it's really rather good isn't it? I want to setup Git on our host and change to Git. Git is released under the GPLv2https://github.com/git/git/blob/master/COPYING open source license http://www.opensource.org/docs/osd. I do not modify Git , just want to run it on our server. So is there any restriction to acquire a commercial license? No. First of course there is no commercial license to acquire for git itself, you can just start to use it. If you make no changes to the git source code there are no obligations to fulfil, all participation in the community (e.g. answering questions on this list) are completely voluntary. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Eagles may soar, but weasels don't get sucked into jet engines. pgp5pa9hzZ9ZJ.pgp Description: PGP signature
