Eric Blake wrote: > Or you could use the relatively new git concept of a shallow clone, which > only grabs the recent state of the repository without all the history. > You can't do as much with a shallow clone, but if all you wanted was a > snapshot of the current state, it fits the bill for smaller disk usage.
Additionally (of course Eric knows this but carrying on the discussion for others...) it is possible to share the repository across multiple working copies. So if someone is were wanting to create several different working copies for several different things it is not required to use another 54MB for every git clone working copy. Assuming: git clone git://git.sv.gnu.org/coreutils Then: git clone -l --reference $PWD/coreutils git://git.sv.gnu.org/coreutils cu-test1 That will reference the files already in the $PWD/coreutils/.git depot without duplicating them on the disk. This works because git depots are effectively static with regard to the previous history. The new cu-test1 depot created above requires that the referenced depot exist but saves on duplicating the disk space. It is also useful to daisy chain depots forward. If a full depot has been cloned once then it may be used to clone the next local depot. This is very fast on a local disk and the depot created does not depend upon the cloned depot. git clone -l $PWD/coreutils cu-test2 That will hardlink the static files from the previous depot history into the newly created depot. The disk space is then shared between them by the use of hard links. du will report file space consumed in both but because it is hard linked the file space is actually shared. The advantage of the hardlinks is that the depot is independent of the first depot. Either may be removed and the other will be fully intact. The disadvantage is that in this last case the automatic setup of the "origin" URL is to the depot cloned which is not the upstream depot but is instead the local disk depot. I guess it is not fully independent because of this but that is the only dependency. The origin URL would need manual editing to point it upstream. Git takes a toolbox approach. A lot of tools are available and the choice of how to use them is yours. But you don't need to use all of the tools all at once. Use only the ones that you wish and leave the others for another time. Bob _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
