Andrew Benton <b3nton@xxxxxxxxx> writes:
> I have a project that I store in a git repository. It's a bunch of source tarballs and
> some bash scripts to compile it all. Git makes it easy to distribute any changes I make
> across the computers I run. The problem I have is that over time the repository gets ever
> larger. When I update to a newer version of something I git rm the old tarball but git
> still keeps a copy and the folder grows ever larger. At the moment the only solution I
> have is to periodically rm -rf .git and start again. This works but is less than ideal
> because I lose all the history for my build scripts.
> What I would like is to be able to tell git to not keep a copy of anything that has been
> git rm. The build scripts never get removed, only altered so their history would be
> preserved. Is it possible to make git delete its backup copies of removed files?
You are either being unreasonable, or haven't thought things through.
Let's say you have your build script with a tarball of frotz-1.42.tar.gz
in the initial revision. The script extracts from tarball and builds.
Now you update your build script once, and make a commit.
Then you add frotz-1.43.tar.gz and remove frotz-1.42.tar.gz. You may
adjust the build script to extract frotz-1.43 instead of frotz-1.42 in the
same commit, or your script may be written loosely and extract any tarball
that matches frotz-*.tar.gz wildcard in which case the build script may
not change.
You now have three commits:
- initial one: ships frotz-1.42 and builds it;
- second one: ships frotz-1.42 and builds it better;
- third one: ships frotz-1.43 and builds it in some way.
You clone it to some other machine and build the tip; everything goes well
and you are happy. What should happen if you do:
$ git checkout HEAD^
$ make
Should it build frotz-1.43, or should it fail?
If you somehow obliterate frotz-1.42.tar.gz out of the history with some
magic you described, there should not be any frotz-1.42.tar.gz in the
history, so there is no way you can build frotz-1.42 out of this checkout.
Your "second" tree can only have one or two shapes:
- It can record only build script and nothing else, in which case the
above "make" will have to fail.
- With some magic you described, it records your build script and
frotz-1.43.tar.gz, and frotz-1.43 is built.
You need to realize that the magic have to adjust your build script so
that it does not require the exact version of frotz-1.42. Namely, the
build script you wrote not only knew that the next version of tarball will
match frotz-*.tar.gz (and that is why you can extract the contents from
it), but also somehow anticipated the build infrastructure change the
upstream will make when they update from 1.42 to 1.43 and was magically
capable of building either versions. And you did that back when you
didn't have the source to frotz-1.43 and how it would look like.
You also need to realize that nowhere in your set-up up to the point you
made three commits, you never told anybody that frotz-1.43.tar.gz replaces
frotz-1.42.tar.gz. The only thing you said was to remove frotz-1.42.tar.gz.
If you make the checkout of second one to fail to build because your
"obliterate" is not to include any tarball in the second version, then you
are being unreasonable.
If you are asking for the magic to include frotz-1.43 instead of
frotz-1.42, and further adjust your old build script to anticipate
the change between 1.42 and 1.43, you haven't described how that magic
should happen, so you haven't thought things through.
One way out would be to do it like this instead:
- initial one: your build script, and frotz-1.42 extracted in frotz/
directory already. Do not ship a tarball.
- second one: your improved build script, and the same frotz/ directory
without any change.
- third one: your build script, either improved or the same from the
previous one, and frotz-1.43 extracted in frotz/ directory.
This way, the checkout from the second one will build frotz-1.42. Also
you could see if your build scripts from the second version would build
frotz-1.43 as well by doing something like:
$ git checkout HEAD^
$ git checkout master -- frotz/
$ make
You will ship both versions of frotz, but between 1.42 and 1.43 there will
be a lot of similarities, so packed result will be far smaller than
storing two compressed tarballs. In fact, I wouldn't be surprised if it
were smaller than storing one compressed tarball.
--
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