Re: [git-users] Large SVN to GIT migration
Thanks Mark, All advice so far seems to trend towards taking opportunity to clean up repository. I'm doing a walk through Clone of latest Dev Branch into GIT. I want to see how to manage the Clone and then keep synchronized. And then evenutally push or clone into a central repository that Developers would connect to. Kevin On Thursday, November 3, 2016 at 3:58:12 PM UTC-7, Mark Waite wrote: > > > > On Thursday, November 3, 2016 at 10:31:08 AM UTC-6, Kevin Norton wrote: >> >> Thanks Magnus, >> >> i will explore subgit, but i think i'm leaning towards simplifying my >> repo and trimming un-needed branches and history. >> > > When we did a major transition from a previous source control system to > git, it was easiest and simplest to take a snapshot of the tip of the > relevant branches from the source repository, then place them into the new > git repository. Developers who want to see the history before the > transition referred to the earlier repository. Developers who want the > history after the transition referred to the git repository. > > I think that had several benefits: > >1. Don't mislead developers to think that the history in git is >authoritative for those commits before git was used. The authoritative >history is in the original repository >2. Don't clutter the new repository with history that precedes the >transition to git >3. Don't spend time trying to create and revise a translation system >when the translated result will not be authoritative > > I'm sure there are business conditions where that is not acceptable > (transition from a licensed, proprietary source control system which will > be unavailable after the transition), but it worked well for us, and it > wasn't too long before searches in the old repository dropped to almost > zero. > > > Mark Waite > > >> Kevin >> >> On Thursday, November 3, 2016 at 1:18:53 AM UTC-7, Magnus Therning wrote: >>> >>> >>> Kevin Norton writes: >>> >>> > i'm in the process of coming up with a strategy to convert a very >>> large >>> > project from SVN to GIT. >>> > >>> > i'm experimented with git svn clone but have some questions. >>> > >>> > how large is to large. >>> > >>> > current SVN repo >>> > 80K+ revisions. >>> > suffers from poor SCM practices >>> > current structure in SVN is using cascading hierarchy. Essentially >>> each >>> > release branch becomes the trunk (not officially named as trunk) and >>> then >>> > next release branches to start next development release branch and so >>> on, >>> > Think of a stairway. >>> > Essentially current code sitting in Trunk is extremely old, relevant >>> code >>> > is at the end of the branching staircase. >>> > >>> > My first issue i'm trying to sort out. >>> > Should i migrate the entire SVN repo into a staging GIT repo and then >>> clean >>> > up the GIT repo before pushing to eventual network repo for all >>> developers. >>> > Will it even clone at this size? >>> > Or i could clone only the latest release branch and start this as my >>> Master >>> > in GIT. >>> > Questions with this approach are how do i keep it from walking the >>> branches >>> > back through entire SVN repo? >>> > Only way I've seen so far is to specify SVN revision. Is there another >>> > approach i'm overlooking. >>> > Advantage here is smaller conversion but i'm loosing history or have >>> to >>> > maintain a legacy SVN repo for historical. (maybe its not important?) >>> > >>> > any experience or suggestions with the above are appreciated. >>> >>> Just bumped into this too >>> https://github.com/svn-all-fast-export/svn2git. In particular this >>> passage sounds like it could be interesting: >>> >>> The svn2git repository gets you an application that will do the actual >>> conversion. The conversion exists of looping over each and every >>> commit in the subversion repository and matching the changes to a >>> ruleset after which the changes are applied to a certain path in a git >>> repo. >>> >>> I don't know, but maybe you can come up with rules that'll convert your >>> "staircase development" in SVN to a more common "single branch >>> development with release branches"? >>> >>> /M >>> >>> -- >>> Magnus Therning OpenPGP: 0x927912051716CE39 >>> email: mag...@therning.org jabber: mag...@therning.org >>> twitter: magthe http://therning.org/magnus >>> >>> We act as though comfort and luxury were the chief requirements of >>> life, when all that we need to make us happy is something to be >>> enthusiastic about. >>> — Albert Einstein >>> >> -- 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/d/optout.
Re: [git-users] Large SVN to GIT migration
On Thursday, November 3, 2016 at 10:31:08 AM UTC-6, Kevin Norton wrote: > > Thanks Magnus, > > i will explore subgit, but i think i'm leaning towards simplifying my repo > and trimming un-needed branches and history. > When we did a major transition from a previous source control system to git, it was easiest and simplest to take a snapshot of the tip of the relevant branches from the source repository, then place them into the new git repository. Developers who want to see the history before the transition referred to the earlier repository. Developers who want the history after the transition referred to the git repository. I think that had several benefits: 1. Don't mislead developers to think that the history in git is authoritative for those commits before git was used. The authoritative history is in the original repository 2. Don't clutter the new repository with history that precedes the transition to git 3. Don't spend time trying to create and revise a translation system when the translated result will not be authoritative I'm sure there are business conditions where that is not acceptable (transition from a licensed, proprietary source control system which will be unavailable after the transition), but it worked well for us, and it wasn't too long before searches in the old repository dropped to almost zero. Mark Waite > Kevin > > On Thursday, November 3, 2016 at 1:18:53 AM UTC-7, Magnus Therning wrote: >> >> >> Kevin Norton writes: >> >> > i'm in the process of coming up with a strategy to convert a very large >> > project from SVN to GIT. >> > >> > i'm experimented with git svn clone but have some questions. >> > >> > how large is to large. >> > >> > current SVN repo >> > 80K+ revisions. >> > suffers from poor SCM practices >> > current structure in SVN is using cascading hierarchy. Essentially each >> > release branch becomes the trunk (not officially named as trunk) and >> then >> > next release branches to start next development release branch and so >> on, >> > Think of a stairway. >> > Essentially current code sitting in Trunk is extremely old, relevant >> code >> > is at the end of the branching staircase. >> > >> > My first issue i'm trying to sort out. >> > Should i migrate the entire SVN repo into a staging GIT repo and then >> clean >> > up the GIT repo before pushing to eventual network repo for all >> developers. >> > Will it even clone at this size? >> > Or i could clone only the latest release branch and start this as my >> Master >> > in GIT. >> > Questions with this approach are how do i keep it from walking the >> branches >> > back through entire SVN repo? >> > Only way I've seen so far is to specify SVN revision. Is there another >> > approach i'm overlooking. >> > Advantage here is smaller conversion but i'm loosing history or have to >> > maintain a legacy SVN repo for historical. (maybe its not important?) >> > >> > any experience or suggestions with the above are appreciated. >> >> Just bumped into this too >> https://github.com/svn-all-fast-export/svn2git. In particular this >> passage sounds like it could be interesting: >> >> The svn2git repository gets you an application that will do the actual >> conversion. The conversion exists of looping over each and every >> commit in the subversion repository and matching the changes to a >> ruleset after which the changes are applied to a certain path in a git >> repo. >> >> I don't know, but maybe you can come up with rules that'll convert your >> "staircase development" in SVN to a more common "single branch >> development with release branches"? >> >> /M >> >> -- >> Magnus Therning OpenPGP: 0x927912051716CE39 >> email: mag...@therning.org jabber: mag...@therning.org >> twitter: magthe http://therning.org/magnus >> >> We act as though comfort and luxury were the chief requirements of >> life, when all that we need to make us happy is something to be >> enthusiastic about. >> — Albert Einstein >> > -- 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/d/optout.
Re: [git-users] Best Practices around version control / configuration management of Python / Spark Machine Learning Models on Git
Well I think that in the end it's just code, maybe the difference it's that this code changes very often. Just make a commit every time you achieve something (or some task is completed). If you are worried about having different versions of a same model, you can use branches to keep them organized. You can search about git workflows to have a better idea of the different approaches (maybe these workflows are overkill for your problem). Sorry if I oversimplified your problem! El jue., 3 de nov. de 2016 a la(s) 14:02, Debabrata Ghosh < mailford...@gmail.com> escribió: > Hi, > Greetings ! > > I need certain best practices / guidance around how to > effectively version control advance analytical models written in Python / > Spark on Git. The advanced analytical models are a bit different to the > normal Java code. As the training of the advanced analytical models is > iterative therefore any guidance around at what time we should commit the > code into Git will be quite useful for me. > > Thanks for your response in advance ! > > > Thanks, > > Debu > > -- > 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/d/optout. > -- 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/d/optout.
[git-users] Best Practices around version control / configuration management of Python / Spark Machine Learning Models on Git
Hi, Greetings ! I need certain best practices / guidance around how to effectively version control advance analytical models written in Python / Spark on Git. The advanced analytical models are a bit different to the normal Java code. As the training of the advanced analytical models is iterative therefore any guidance around at what time we should commit the code into Git will be quite useful for me. Thanks for your response in advance ! Thanks, Debu -- 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/d/optout.
[git-users] Re: Large SVN to GIT migration
Thanks Nando, I have attempted clone of entire repo. Basically i believe it will complete most likely afer a few days of restarts after failures. But most likely i need to take this opportunity to trim my repo and only clone what is necessary. Old versions of code are most likely not valuable and this is a good opportunity to take a fresh start. My goal is to introduce better SCM practices, so the cleaner the repo, most likely the better chance of success. . On Thursday, November 3, 2016 at 12:11:34 AM UTC-7, Ferdinando Santacroce wrote: > > Hi Kevin. > > Il giorno mercoledì 2 novembre 2016 19:48:58 UTC+1, Kevin Norton ha > scritto: >> >> i'm in the process of coming up with a strategy to convert a very large >> project from SVN to GIT. >> >> i'm experimented with git svn clone but have some questions. >> >> how large is to large. >> > >> current SVN repo >> 80K+ revisions. >> suffers from poor SCM practices >> current structure in SVN is using cascading hierarchy. Essentially each >> release branch becomes the trunk (not officially named as trunk) and then >> next release branches to start next development release branch and so on, >> Think of a stairway. >> Essentially current code sitting in Trunk is extremely old, relevant code >> is at the end of the branching staircase. >> >> My first issue i'm trying to sort out. >> Should i migrate the entire SVN repo into a staging GIT repo and then >> clean up the GIT repo before pushing to eventual network repo for all >> developers. >> Will it even clone at this size? >> > > I converted some SVN repo before, but no so big stuff (about 1k revisions). > Have you tried to run the git svn clone command just to see what happens? > It will take hours (please use powerful machine and reliable network), but > I think there's no better way to figure out if it will work. > > >> Or i could clone only the latest release branch and start this as my >> Master in GIT. >> > > This can be a way to set a "cut-line" and start with a new repo and a > better versioning strategy and flow. > > >> Questions with this approach are how do i keep it from walking the >> branches back through entire SVN repo? >> Only way I've seen so far is to specify SVN revision. Is there another >> approach i'm overlooking. >> > > Take a look at --ignore-paths option (https://git-scm.com/docs/git-svn); > you can use Perl regex to restrict the field of your clone command. > > >> Advantage here is smaller conversion but i'm loosing history or have to >> maintain a legacy SVN repo for historical. (maybe its not important?) >> > > Try to do a little retrospective: how much times do you look for old > commits and branches in you actual SVN repo? > Do an year or later old branch has some value for you today? > Or it is only a matter of historical purpose? > I you realize you never look at oldest branches, then I think you can > freeze the actual SVN repo (or convert it to Git but leave it apart) and > then start with a new Git repo with the latest 2-3 branches only. > > >> any experience or suggestions with the above are appreciated. >> > > Software evolves, and long-living repos often are just an heavy load to > drag than a real value. > Starting with a new tool can also be a chance to review your flow a choose > a better strategy (see GiFlow, GitHub flow, GitLab flow, etc.). > If I were in your shoes, I will take this chance and start with a new > smaller repo wit only the latest 2 branches/versions of the software. > > My 2 cents :) > Nando > -- 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/d/optout.
Re: [git-users] Large SVN to GIT migration
Thanks Magnus, i will explore subgit, but i think i'm leaning towards simplifying my repo and trimming un-needed branches and history. Kevin On Thursday, November 3, 2016 at 1:18:53 AM UTC-7, Magnus Therning wrote: > > > Kevin Norton > writes: > > > i'm in the process of coming up with a strategy to convert a very large > > project from SVN to GIT. > > > > i'm experimented with git svn clone but have some questions. > > > > how large is to large. > > > > current SVN repo > > 80K+ revisions. > > suffers from poor SCM practices > > current structure in SVN is using cascading hierarchy. Essentially each > > release branch becomes the trunk (not officially named as trunk) and > then > > next release branches to start next development release branch and so > on, > > Think of a stairway. > > Essentially current code sitting in Trunk is extremely old, relevant > code > > is at the end of the branching staircase. > > > > My first issue i'm trying to sort out. > > Should i migrate the entire SVN repo into a staging GIT repo and then > clean > > up the GIT repo before pushing to eventual network repo for all > developers. > > Will it even clone at this size? > > Or i could clone only the latest release branch and start this as my > Master > > in GIT. > > Questions with this approach are how do i keep it from walking the > branches > > back through entire SVN repo? > > Only way I've seen so far is to specify SVN revision. Is there another > > approach i'm overlooking. > > Advantage here is smaller conversion but i'm loosing history or have to > > maintain a legacy SVN repo for historical. (maybe its not important?) > > > > any experience or suggestions with the above are appreciated. > > Just bumped into this too > https://github.com/svn-all-fast-export/svn2git. In particular this > passage sounds like it could be interesting: > > The svn2git repository gets you an application that will do the actual > conversion. The conversion exists of looping over each and every > commit in the subversion repository and matching the changes to a > ruleset after which the changes are applied to a certain path in a git > repo. > > I don't know, but maybe you can come up with rules that'll convert your > "staircase development" in SVN to a more common "single branch > development with release branches"? > > /M > > -- > Magnus Therning OpenPGP: 0x927912051716CE39 > email: mag...@therning.orgjabber: mag...@therning.org > > twitter: magthe http://therning.org/magnus > > We act as though comfort and luxury were the chief requirements of > life, when all that we need to make us happy is something to be > enthusiastic about. > — Albert Einstein > -- 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/d/optout.
Re: [git-users] Yet more git madness
On Tue, 2016-11-01 at 15:36 -0700, AD S wrote: > Sorry, I meant pull request. Everyone else's code (2,800+ files and > 250+ commits) are suddenly in the pull request I was working on (which > had 8 files and 4 commits). As mentioned this seems more a rant about GitHub and its development model than about Git per se (although of course GitHub simply codifies a particular style of working with Git). Most of my uses of Git are more traditional "hub and spoke" model, with one central Git repository that all the developers use as their sole upstream, via personal branches. It's quite straightforward to work with. Layering a multi-repo, multi-upstream process on top of that does increase the complexity, and potential for errors, significantly I expect. It's important to be able to visualize what's going on internally here so you can determine what the right action is and what the result will be. -- 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/d/optout.
Re: [git-users] Large SVN to GIT migration
Kevin Norton writes: > i'm in the process of coming up with a strategy to convert a very large > project from SVN to GIT. > > i'm experimented with git svn clone but have some questions. > > how large is to large. > > current SVN repo > 80K+ revisions. > suffers from poor SCM practices > current structure in SVN is using cascading hierarchy. Essentially each > release branch becomes the trunk (not officially named as trunk) and then > next release branches to start next development release branch and so on, > Think of a stairway. > Essentially current code sitting in Trunk is extremely old, relevant code > is at the end of the branching staircase. > > My first issue i'm trying to sort out. > Should i migrate the entire SVN repo into a staging GIT repo and then clean > up the GIT repo before pushing to eventual network repo for all developers. > Will it even clone at this size? > Or i could clone only the latest release branch and start this as my Master > in GIT. > Questions with this approach are how do i keep it from walking the branches > back through entire SVN repo? > Only way I've seen so far is to specify SVN revision. Is there another > approach i'm overlooking. > Advantage here is smaller conversion but i'm loosing history or have to > maintain a legacy SVN repo for historical. (maybe its not important?) > > any experience or suggestions with the above are appreciated. Just bumped into this too https://github.com/svn-all-fast-export/svn2git. In particular this passage sounds like it could be interesting: The svn2git repository gets you an application that will do the actual conversion. The conversion exists of looping over each and every commit in the subversion repository and matching the changes to a ruleset after which the changes are applied to a certain path in a git repo. I don't know, but maybe you can come up with rules that'll convert your "staircase development" in SVN to a more common "single branch development with release branches"? /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about. — Albert Einstein -- 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/d/optout. signature.asc Description: PGP signature
Re: [git-users] Large SVN to GIT migration
Kevin Norton writes: > i'm in the process of coming up with a strategy to convert a very large > project from SVN to GIT. > > i'm experimented with git svn clone but have some questions. > > how large is to large. > > current SVN repo > 80K+ revisions. > suffers from poor SCM practices > current structure in SVN is using cascading hierarchy. Essentially each > release branch becomes the trunk (not officially named as trunk) and then > next release branches to start next development release branch and so on, > Think of a stairway. > Essentially current code sitting in Trunk is extremely old, relevant code > is at the end of the branching staircase. > > My first issue i'm trying to sort out. > Should i migrate the entire SVN repo into a staging GIT repo and then clean > up the GIT repo before pushing to eventual network repo for all developers. > Will it even clone at this size? > Or i could clone only the latest release branch and start this as my Master > in GIT. > Questions with this approach are how do i keep it from walking the branches > back through entire SVN repo? > Only way I've seen so far is to specify SVN revision. Is there another > approach i'm overlooking. > Advantage here is smaller conversion but i'm loosing history or have to > maintain a legacy SVN repo for historical. (maybe its not important?) > > any experience or suggestions with the above are appreciated. It's worth taking a look at https://subgit.com/ to see if that tool can simplify the conversion. It's proprietary, but the licensing is reasonable (https://subgit.com/pricing.html). /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus Never be afraid to try something new. Remember, amateurs built the ark; professionals built the Titanic. — Anonymous -- 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/d/optout. signature.asc Description: PGP signature
Re: [git-users] What is git doing with "git submodule update" that I get coo-coo error: "outside repository"
Xtian Simon writes: > I'm getting this rather coo-coo error when using the Vim package manager > [Vundle][1]'s :PluginUpdate command. If you're not familiar with Vundle, it > lets you update your Vim plugin git packages. > > I've narrowed the problem down to the `submodule update` operation. Sure > enough, if I use the same command from Bash, I get the same error: > > $ pwd > /home/mastershake/xtian/.vim/bundle/closetag.vim > $ ls -al > total 20K > drwxr-xr-x 4 xtian xtian 4.0K Apr 11 2015 . > drwxr-xr-x 24 xtian xtian 4.0K Oct 24 2015 .. > drwxr-xr-x 8 xtian xtian 4.0K Oct 31 09:05 .git > drwxr-xr-x 2 xtian xtian 4.0K Apr 11 2015 plugin > -rw-r--r-- 1 xtian xtian 1.5K Apr 11 2015 README > $ git submodule update --init --recursive > fatal: /home/mastershake/xtian/Documents.x/Employment.d/Jobs.d: > '/home/mastershake/xtian/Documents.x/Employment.d/Jobs.d' is outside > repository > > What's more, any directory (with a git repo) where I perform this same > operation I get the same error. I say it's coo-coo, because the error has > nothing to do with any individual `.git` repo itself. > > I'm running ArchLinux. I've not done anything custom. I've just updated as > per usual. > > What's git doing, and how do I fix it? I've used Vundle extensively and never bumped into this particular issue. I notice you don't have a .gitmodules file in the folder in question. So, maybe you'll find the reason for the oddity if you first locate the .gitmodules file that produces that error? /M -- Magnus Therning OpenPGP: 0x927912051716CE39 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus You do not examine legislation in the light of the benefits it will convey if properly administered, but in the light of the wrongs it would do and the harms it would cause if improperly administered. — Lyndon Johnson -- 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/d/optout. signature.asc Description: PGP signature
[git-users] Re: Large SVN to GIT migration
Hi Kevin. Il giorno mercoledì 2 novembre 2016 19:48:58 UTC+1, Kevin Norton ha scritto: > > i'm in the process of coming up with a strategy to convert a very large > project from SVN to GIT. > > i'm experimented with git svn clone but have some questions. > > how large is to large. > > current SVN repo > 80K+ revisions. > suffers from poor SCM practices > current structure in SVN is using cascading hierarchy. Essentially each > release branch becomes the trunk (not officially named as trunk) and then > next release branches to start next development release branch and so on, > Think of a stairway. > Essentially current code sitting in Trunk is extremely old, relevant code > is at the end of the branching staircase. > > My first issue i'm trying to sort out. > Should i migrate the entire SVN repo into a staging GIT repo and then > clean up the GIT repo before pushing to eventual network repo for all > developers. > Will it even clone at this size? > I converted some SVN repo before, but no so big stuff (about 1k revisions). Have you tried to run the git svn clone command just to see what happens? It will take hours (please use powerful machine and reliable network), but I think there's no better way to figure out if it will work. > Or i could clone only the latest release branch and start this as my > Master in GIT. > This can be a way to set a "cut-line" and start with a new repo and a better versioning strategy and flow. > Questions with this approach are how do i keep it from walking the > branches back through entire SVN repo? > Only way I've seen so far is to specify SVN revision. Is there another > approach i'm overlooking. > Take a look at --ignore-paths option (https://git-scm.com/docs/git-svn); you can use Perl regex to restrict the field of your clone command. > Advantage here is smaller conversion but i'm loosing history or have to > maintain a legacy SVN repo for historical. (maybe its not important?) > Try to do a little retrospective: how much times do you look for old commits and branches in you actual SVN repo? Do an year or later old branch has some value for you today? Or it is only a matter of historical purpose? I you realize you never look at oldest branches, then I think you can freeze the actual SVN repo (or convert it to Git but leave it apart) and then start with a new Git repo with the latest 2-3 branches only. > any experience or suggestions with the above are appreciated. > Software evolves, and long-living repos often are just an heavy load to drag than a real value. Starting with a new tool can also be a chance to review your flow a choose a better strategy (see GiFlow, GitHub flow, GitLab flow, etc.). If I were in your shoes, I will take this chance and start with a new smaller repo wit only the latest 2 branches/versions of the software. My 2 cents :) Nando -- 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/d/optout.
