[git-users] Re: Submodules and clobbering history
On Wednesday, January 29, 2014 12:16:59 AM UTC+1, 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? What about delivering the software in shape of a git-archivehttps://www.kernel.org/pub/software/scm/git/docs/git-archive.html? It will output a compressed archive without history (which is smaller than the respective .git repository). If you have multiple repositories (submodules), just do a git-archive in every repository, and then ship them together. Make a script to repeat the process. -- 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] Re: Submodules and clobbering history
If you have multiple repositories (submodules), just do a git-archive in every repository, and then ship them together. Make a script to repeat the process. I just came across this script which should help with the above: https://github.com/Kentzo/git-archive-all -- 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.
[git-users] content of pushed files
it might be an easy one but somehow I am not sure how to get my hands on it. I want to have a hook which checks the content of the a file and to decide whether to deny or accept the push by some validation on the content. how do I extract the content of the related files ? (bare repo of course) I know that git show branch name:path will do, but that is for the current objects in the repo. what I need are the pushed ones, before it's being applied. thanks in advance. Gabby. -- 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] content of pushed files
On Wed, 29 Jan 2014 06:51:48 -0800 (PST) Gabby Romano omerik...@gmail.com wrote: it might be an easy one but somehow I am not sure how to get my hands on it. I want to have a hook which checks the content of the a file and to decide whether to deny or accept the push by some validation on the content. how do I extract the content of the related files ? (bare repo of course) I know that git show branch name:path will do, but that is for the current objects in the repo. what I need are the pushed ones, before it's being applied. Your problem is that you're supposedly stuck with the idea that `git show` has to take a branch name while in fact it might be any commitish--a specification which is resolvable to the SHA-1 name of a commit; this might be a branch name, a tag name, the SHA-1 name of a commit, directly, something involved like foo~5^3 and so on (see the gitrevisions manual page for more details). What this has to do with your problem is that pre-/post-receive and update hooks receive a list of refs to be updated--each along with the two SHA-1 names of commits: one is what that ref currently points at, and another one is its prospective replacement. The details are in the githooks manual page. So your hook program, for each ref to be updated, should parse out the SHA-1 name of its prospective new commit, check it's not just forty 0 characters, meaning the ref is about to be deleted, and if these checks pass, call `git show sha1name:path` and do whatever it pleases with the contents of that blob. Note that you're telling about current objects in the repo and the fact is the objects received during the push operation *are* in the repo by the time the appropriate hooks run, just the refs (heads, tags etc) are not yet updated to point to the new values. Should a pre- or post-receive hook exit with a non-zero return code, and the refs won't be updated and the received objects will be eventually garbage-collected (because they are orphan--not referenced by any live ref). As usually, you have to be prepared to deal with two things: * The path might legitimately not exist in a commit, in which case `git show` will fail, and you have to be prepared to somehow handle this case. * Using the way just explained, you'll be checking just the tip commit but a push operation might update a ref with arbitrary graph of commits (that is, not just a single commit and not even with just a straight line of commits), so if you want to be sure the blob recorded under the name path exists in *each* of the commits of that graph, and has sensible contents there, you'll have to arrange for walking that graph, checking each commit along the way. You might consider reading [1] and [2] useful. 1. https://groups.google.com/d/msg/git-users/Tj1W7Xuqybw/zQhFbPLks-gJ 2. https://groups.google.com/d/msg/git-users/DzxY0wkyJPE/mFFL83Lm6wsJ -- 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] content of pushed files
As usual, very detailed answer. couldn't ask for more. I knew that git show is very useful, just didn't know how much...:-) thanks a lot. On Wed, Jan 29, 2014 at 6:13 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Wed, 29 Jan 2014 06:51:48 -0800 (PST) Gabby Romano omerik...@gmail.com wrote: it might be an easy one but somehow I am not sure how to get my hands on it. I want to have a hook which checks the content of the a file and to decide whether to deny or accept the push by some validation on the content. how do I extract the content of the related files ? (bare repo of course) I know that git show branch name:path will do, but that is for the current objects in the repo. what I need are the pushed ones, before it's being applied. Your problem is that you're supposedly stuck with the idea that `git show` has to take a branch name while in fact it might be any commitish--a specification which is resolvable to the SHA-1 name of a commit; this might be a branch name, a tag name, the SHA-1 name of a commit, directly, something involved like foo~5^3 and so on (see the gitrevisions manual page for more details). What this has to do with your problem is that pre-/post-receive and update hooks receive a list of refs to be updated--each along with the two SHA-1 names of commits: one is what that ref currently points at, and another one is its prospective replacement. The details are in the githooks manual page. So your hook program, for each ref to be updated, should parse out the SHA-1 name of its prospective new commit, check it's not just forty 0 characters, meaning the ref is about to be deleted, and if these checks pass, call `git show sha1name:path` and do whatever it pleases with the contents of that blob. Note that you're telling about current objects in the repo and the fact is the objects received during the push operation *are* in the repo by the time the appropriate hooks run, just the refs (heads, tags etc) are not yet updated to point to the new values. Should a pre- or post-receive hook exit with a non-zero return code, and the refs won't be updated and the received objects will be eventually garbage-collected (because they are orphan--not referenced by any live ref). As usually, you have to be prepared to deal with two things: * The path might legitimately not exist in a commit, in which case `git show` will fail, and you have to be prepared to somehow handle this case. * Using the way just explained, you'll be checking just the tip commit but a push operation might update a ref with arbitrary graph of commits (that is, not just a single commit and not even with just a straight line of commits), so if you want to be sure the blob recorded under the name path exists in *each* of the commits of that graph, and has sensible contents there, you'll have to arrange for walking that graph, checking each commit along the way. You might consider reading [1] and [2] useful. 1. https://groups.google.com/d/msg/git-users/Tj1W7Xuqybw/zQhFbPLks-gJ 2. https://groups.google.com/d/msg/git-users/DzxY0wkyJPE/mFFL83Lm6wsJ -- 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] Git github not working with google authenticator OSX
So I had git running on my computer just fine. My password was saved with the osxkeychain thingy and everything ran smoothly. Today I decided I should be safe and enable google authenticator 2-step authentication on all the sites that support it. Interestingly github supports it so I set it up. It works fine through the website interface. I proceed to branch a project I'm working on and do a bit of work and then I try to push the new branch up. Not surprised at all when I find out my authentication doesn't work. What is surprising to me is that I can't seem to find anything at all on google to solve my problem. my initial error was this: git push --set-upstream origin binary-dev remote: Invalid username or password. fatal: Authentication failed for 'https://github.com/***/***.git/' I then purged my old password stuff to get the interactive prompt with: git credential-osxkeychain erase host=github.com protocol=https And that worked at getting rid of my old settings but now I get: git push --set-upstream origin binary-dev Username for 'https://github.com': *** Password for 'https://***@github.com': remote: Invalid username or password. fatal: Authentication failed for 'https://github.com/***/***.git/' So git itself doesn't seem to know about the google authenticator. I literally can't seem to find any information on this. About half the pages are about how to set it up on the website and the other half are how to fork the actual google authenticator source code. I may not be creative enough with my keywords though. There may also be no solution but then I have to wonder why github offers 2-factor auth at all? Is there anyone out there who's been stuck here like me and has found a way out? Any help would be *greatly* appreciated. I just want git to work like it did before I added the 2-step auth to github. Thanks in advance, Max -- 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] Re: Git github not working with google authenticator OSX
On Thursday, January 30, 2014 4:47:40 AM UTC+1, Max Rahm wrote: So I had git running on my computer just fine. My password was saved with the osxkeychain thingy and everything ran smoothly. Today I decided I should be safe and enable google authenticator 2-step authentication on all the sites that support it. Interestingly github supports it so I set it up. It works fine through the website interface. I proceed to branch a project I'm working on and do a bit of work and then I try to push the new branch up. Not surprised at all when I find out my authentication doesn't work. What is surprising to me is that I can't seem to find anything at all on google to solve my problem. my initial error was this: git push --set-upstream origin binary-dev remote: Invalid username or password. fatal: Authentication failed for 'https://github.com/***/***.git/' I then purged my old password stuff to get the interactive prompt with: git credential-osxkeychain erase host=github.com protocol=https And that worked at getting rid of my old settings but now I get: git push --set-upstream origin binary-dev Username for 'https://github.com': *** Password for 'https://***@github.com': remote: Invalid username or password. fatal: Authentication failed for 'https://github.com/***/***.git/' So git itself doesn't seem to know about the google authenticator. I literally can't seem to find any information on this. About half the pages are about how to set it up on the website and the other half are how to fork the actual google authenticator source code. I may not be creative enough with my keywords though. There may also be no solution but then I have to wonder why github offers 2-factor auth at all? Is there anyone out there who's been stuck here like me and has found a way out? Any help would be *greatly* appreciated. I just want git to work like it did before I added the 2-step auth to github. Thanks in advance, Max This sounds like something you should bring up with GitHub support: https://github.com/contact That said, I haven't enabled GitHub 2 factor authentication myself, but I'm guessing that it has nothing to do whatsoever with Git authentication over HTTPS and SSH (i.e., everything command line). It only applies to the web login to your account on github.com. Regarding the Google Authenticator, it's just a tool for Android/iPhone, and that doesn't apply in your case since you're on the command line. I'm not sure why you're mixing that in here. Read through https://help.github.com/articles/updating-credentials-from-the-osx-keychain and https://help.github.com/articles/about-two-factor-authentication for more information, and if that doesn't clear things up, please contact GitHub. -- 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.
