Re: [git-users] Submodules and clobbering history
From: Eric Reischer To: git-users@googlegroups.com 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 command. Anyone have any thoughts on how to accomplish all this? Eric 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) Philip -- 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] Submodules and clobbering history
On 01/29/14 00:16, Eric Reischer wrote: 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 command. Anyone have any thoughts on how to accomplish all this? We did something similar using ClearCase a long time ago. I would separate the development repos from the customer repos. The customer repos would contain snapshots from the development repos, with one patch per release. You would basically be squashing the history to one commit per release for the customers. I would write a release script along these lines: # Assuming dev repos have the same tag for each release from_tag=$1 to_tag=$2 for r in dev repos; do cd $r git diff -p $from_tag $to_tag /tmp/$r-$to_tag.patch cd $r_customer # Go to corresponding customer repo patch -p0 /tmp/$r-$to_tag.patch git add . git commit -m Release notes ... git tag ... done cd $customer_super_repo git add . git commit -m Release notes ... git tag ... # Continue with packing super-repo to customer... BR Gunnar -- 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] Submodules and clobbering history
git-archive seems interesting, but alas, I *do* want to deliver a git repository, because there will be times (albeit rare) where we may code up a quick on-site fix at the customer site, and want to be able to conveniently deliver that update back to our shop. git-bundle is ideally suited for that situation, and if I'm just using git to package up the source files, I can accomplish the same thing just by removing the .git folder. I'm thinking a series of scripts that makes the necessary shallow clones and packages up the resulting repositories is probably going to be my best solution, and just dropping the super-repo idea. It was just a convenience thing (there isn't any code in the top-level folder for the super-repo to track), so it's looking like that would be providing more work than benefit. -- 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] Submodules and clobbering history
On Wednesday, January 29, 2014 6:01:05 PM UTC+1, Eric Reischer wrote: git-archive seems interesting, but alas, I *do* want to deliver a git repository, because there will be times (albeit rare) where we may code up a quick on-site fix at the customer site, and want to be able to conveniently deliver that update back to our shop. git-bundle is ideally suited for that situation What I would do here (I think, but it's not easy to say from outside), if the need for a quick on-site fix arises, would be to do a quick git-init add their source code, do the quick fixes, and then bring the fixes home in shape of patch-files. , and if I'm just using git to package up the source files, I can accomplish the same thing just by removing the .git folder. Perhaps, but git archive is safer, faster and easier. I'm thinking a series of scripts that makes the necessary shallow clones and packages up the resulting repositories is probably going to be my best solution, and just dropping the super-repo idea. It was just a convenience thing (there isn't any code in the top-level folder for the super-repo to track), so it's looking like that would be providing more work than benefit. OK, but it does sound a wee bit complicated. Whatever floats your boat :) -- 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] 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 command. Anyone have any thoughts on how to accomplish all this? -- 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.
