From: Eric Reischer 
  Sent: Tuesday, January 28, 2014 11:16 PM
  Subject: [git-users] Submodules and clobbering history

  I have a fairly esoteric situation, but I suspect I'm probably not the only 
one who is attempting to do something along these lines.  I have a software 
product that consists of a number of Git repositories, each with its own group 
of engineers working on it (think of MATLAB (R) with its plethora of 
toolboxes).  When we deliver software to customers, we ideally would have a 
superproject that references each repo such that we can just have bare 
repositories that are delivered (i.e. zip up the superproject after removing 
all source code), and then on-site the customer runs a program that performs a 
"reset --hard" to get all the source code back.  Easy enough.  (Before everyone 
asks, it's because the source code occupies several hundred megabytes, so 
having everything compressed in the repo is convenient for keeping the media 
count low.)

  The rub comes in that we do not want our customers to see all of our 
development history (and our sometimes not-so-professional commit remarks).  
I've read about a shallow clone (i.e. --depth 1), but it is my understanding 
these types of repos cannot be used with git-bundle.  It does seem to follow 
everything else though, in that updates that occur upstream (i.e. bugfixes to a 
major revision) will be successfully applied with a pull or fetch.  The other 
issue is the --depth flag doesn't seem to be supported with the submodule 

  Anyone have any thoughts on how to accomplish all this?

Have a look at 'git archive' as a mechanism for generating a zip file of the 
latest and greatest that excludes history.

The other option is that 'git shallow' is about to become a first class 
participant, but your concerns about potentially exposing history to clients 
would still be a concern. (i.e. accidently fetching more than you wanted into 
their repo)

You also have the option (assuming an XY problem) of using 'git archive' and 
then starting a new repo from that initial point, and then using grafts if you 
have on-site developments that you want to return to base (though careful use 
of shallow may be just as effective)


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 
For more options, visit

Reply via email to