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/
$ makeYou 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.
