{"thread":{"id":"23869","subject":"What's the best way to make my company migrate to Git?","startedAt":"2010-05-21T14:55:37Z","lastAt":"2010-06-06T08:19:08Z","messageCount":27,"participants":["Daniele Segato","Jakub Narebski","Andrew Sayers","Joshua Jensen","Lin Mac","Michael J Gruber","Alexander Iljin","Erik Faye-Lund","Andreas Krey","Sylvain Rabot","Steven Michalske"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"142035","messageId":"AANLkTikwpjtJnR856CHr_O3856JoMrFBgOQGODXNBbeI@mail.gmail.com","threadId":"23869","inReplyTo":null,"subject":"What's the best way to make my company migrate to Git?","fromName":"Daniele Segato","fromEmail":"daniele.bilug@gmail.com","sentAt":"2010-05-21T14:55:37Z","receivedAt":"2010-05-21T14:55:37Z","isPatch":false,"sender":{"key":"daniele.bilug@gmail.com","avatar":null},"body":"Hi,\n\nI work as a Developer (mainly Java and web applications) and I'd like\nto introduce my company to the use of Git.\nI don't have much time to allocate on this matter, so the elapsed for\napplying any of your suggestion will probably go from weeks to months\n:)\n\nIf I manage to migrate I'll be only able to start using git with the\nnew projects, I don't think that old project will be easily migrated\nto Git (unless not until it will be widely accepted and learned by\neveryone).\nThere are, more or less, 30 developers working in different projects\nfrom junior to senior developers.\n\n\nWe use Subversion as versioning system.\n\nThe developers are used to work with Eclipse (an open source IDE) that\nhappen to have a Subversion plugin and they all works on Windows\nplatform.\nI'm the only one who work on a Linux box and use git-svn from command\nline as a front end to Subversion.\nI already know of (some of) the advantage of using git, but I'm also\naware that it's not that easy to change other people mind on what they\nused for years.\nSo I need to be really persuasive on the advantage of using it, and I\nthink you can help me on this.\n\nI think that to introduce git in my company I should at least go throw\nthis 5 points:\n1. prepare a project management web application easy to use and\nmantain (like github or gitorious for instance) on one of our intranet\nservers.\n2. achieve knowledge on the git-submodule and to handle binary files\nversioning (mainly third party java libraries that are in every\nproject)\n3. learn what I had to know to use Git on windows (i never did this),\nand find some user friendly AND graphical tool to propose (i know\nthere is a Git-eclipse module but I don't know if it is considered\nstable and/or full featured)\n4. give my managers some reason to migrate/begin to use Git instead of\nSubversion\n5. do some \"school\" to other developers\n\n\n\nI think there are many of you that went throw this before and I'd like\nto have some advice on the 5 point of the list above.\n\nCan you also tell me if you think there is some risk in migrating and\nwhat kind of difficult I could encounter in the process?\nFor example: like any company we have a proxy and a firewall..\nFor example: if i had to commit something working from home I connect\nto the Subversion via HTTPS and commit, with Git I should have ssh\naccess which is something that I probably will not have.\n\n\nI can summarize all this email with just this question: What's the\nbest way to make my company migrate to Git?\n\nthank you all for any advice.\n\nDaniele\n"},{"id":"142045","messageId":"m34oi1s13e.fsf@localhost.localdomain","threadId":"23869","inReplyTo":"AANLkTikwpjtJnR856CHr_O3856JoMrFBgOQGODXNBbeI@mail.gmail.com","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-05-21T15:54:03Z","receivedAt":"2010-05-21T15:54:03Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Daniele Segato <daniele.bilug@gmail.com> writes:\n\n[...]\n> I think that to introduce git in my company I should at least go throw\n> this 5 points:\n\n> 1. prepare a project management web application easy to use and\n>    mantain (like github or gitorious for instance) on one of our\n>    intranet servers.\n\nNote that while Gitorious (in Ruby), InDefero (in PHP), and Girocco\n(with gitweb, Perl + shell script, used by http://repo.or.cz) are open\nsource, GitHub is not.  There is GitHub:FI if you want [self] hosted\nGitHub-alike, but it is proprietary and it is not cheap.\n\nThere is also Gerrit, a web based code review system, which runs in\nany standard Java servlet container.\n\n[...]\n> Can you also tell me if you think there is some risk in migrating and\n> what kind of difficult I could encounter in the process?\n> For example: like any company we have a proxy and a firewall..\n> For example: if i had to commit something working from home I connect\n> to the Subversion via HTTPS and commit, with Git I should have ssh\n> access which is something that I probably will not have.\n\nActually with never Git you can push and pull via HTTP(S) natively,\nthanks to git-http-backend.  With older Git you had to use HTTP as\n\"dumb\" protocol, using HTTPS + WebDAV to push (note that for \"dumb\"\nservers git-update-server-info must be run, e.g. via a hook).\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"142088","messageId":"4BF7B751.7050704@pileofstuff.org","threadId":"23869","inReplyTo":"AANLkTikwpjtJnR856CHr_O3856JoMrFBgOQGODXNBbeI@mail.gmail.com","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Andrew Sayers","fromEmail":"andrew-git@pileofstuff.org","sentAt":"2010-05-22T10:52:01Z","receivedAt":"2010-05-22T10:52:01Z","isPatch":false,"sender":{"key":"andrew-git@pileofstuff.org","avatar":null},"body":"Hi Daniele,\n\nI'm a developer getting towards the end of introducing my company to \nGit.  Here are some thoughts based on the (mis)steps I took.\n\n\nI found that advocating specific steps wasn't that effective - I just \ncame across as being pushy and hard to work with.  It was more effective \nto politely show off what I could do with git-svn, and let people get \njealous enough to work the \"how\" out for themselves.  Here are some \nexamples:\n\nI would quietly bisect a hard-to-fix bug, then say \"if it's any help, \ngit tells me it was introduced by so-and-so in revision N\".  Sometimes \nit was no help, but sometimes it was enough to provoke the appropriate \n\"aha!\" for the bug.\n\nI would nonchalantly use as many git features as I could while showing \npeople my work.  So \"here's the diff for my work... grr whitespace ... \nhang on I'll add `-w`... anyway, these are the REAL differences...\". The \nfact it was all in glorious technicolour went without mention.\n\nWhen we had a big merge that nobody was looking forward to, I said \"let \nme do it!  It'll give me a chance to practice my git-fu\".\n\nWhen I used svn on somebody else's command-line, I'd blame the mistakes \nI made on being spoiled by Git.  So \"I'll just do an `svn log`... argh \nno!  Control-C!  Control-C!  Right, `svn log | less`... my bad, git \npipes to less automatically.\"\n\n\nOver the course of a few months, people became convinced that Git was \nsomething that makes you more productive.  Our lead developer had a go \nwith git-svn for a while, before our boss decided we should all make the \nswitch.\n\nI tried to make git-svn as painless as possible with some svn-like \naliases and a cheatsheet, which I'd be happy to upload if the list could \nsuggest a good place to put a PDF and some text.\n\nThe move worked for a while, but it turned out that one-and-a-half git \nexperts supporting the rest of the team wasn't enough to stop people \nfrom making rookie mistakes like `git merge`ing into an SVN branch with \nunpushed changes.  We had to accelerate our move to git on the server, \nand I got a lot of exercise and not much work done that month as I \ndashed from desk to desk.\n\nThings gradually calmed down as people got more comfortable with git. \nBut I expect to be occasionally called over for a long time as people \nlearn new tricks - \"how do I, like, cherry-unpick a single commit?\"\n\n\t- Andrew Sayers\n"},{"id":"142102","messageId":"1274543552.21346.166.camel@Luffy","threadId":"23869","inReplyTo":"4BF7B751.7050704@pileofstuff.org","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Daniele Segato","fromEmail":"daniele.bilug@gmail.com","sentAt":"2010-05-22T15:52:31Z","receivedAt":"2010-05-22T15:52:31Z","isPatch":false,"sender":{"key":"daniele.bilug@gmail.com","avatar":null},"body":"Il giorno sab, 22/05/2010 alle 11.52 +0100, Andrew Sayers ha scritto:\n> Hi Daniele,\n> \n> I'm a developer getting towards the end of introducing my company to \n> Git.  Here are some thoughts based on the (mis)steps I took.\n\nthanks\n\n\n> I found that advocating specific steps wasn't that effective - I just \n> came across as being pushy and hard to work with.  It was more effective \n> to politely show off what I could do with git-svn, and let people get \n> jealous enough to work the \"how\" out for themselves.  Here are some \n> examples:\n> \n> I would quietly bisect a hard-to-fix bug, then .... [big-snip]\n> \n> Over the course of a few months, people became convinced that Git was \n> something that makes you more productive.  Our lead developer had a go \n> with git-svn for a while, before our boss decided we should all make the \n> switch.\n\nI'm already doing this stuff..\nbut i'm in the *lead developer* position now, so, if I say that they had\nto start using git (at least my team) they will..\n\nBut I don't thing going throw git-svn is a good idea.. it has some\nlimitation over the normal git and you have to be more careful about\nrebasing (interactive) and you should avoid merge (as much as I\nunderstood it).\n\nI'd like to make the big move going directly to git.\nI don't think i'll had the time to do it now, the new project is already\ngoing on.. but I'd like to have all prepared and ready for the next\none :)\n\n\n> I tried to make git-svn as painless as possible with some svn-like \n> aliases and a cheatsheet, which I'd be happy to upload if the list could \n> suggest a good place to put a PDF and some text.\n\nI think that may be useful to many.\nIn my specific case it wouldn't help, since everybody is used to click\naround with the git-svn graphical interface, they don't even know the\nsvn commands to do those stuffs. They are almost all windows-minded :)\nyou know: \"writing when you can click? why?\" - I use to think the\nopposite :)\n\nWhat i mean here is: git should be graphical, at least at the beginning,\nbetter if inside eclipse itself.\n\n> The move worked for a while, but it turned out that one-and-a-half git \n> experts supporting the rest of the team wasn't enough to stop people \n> from making rookie mistakes like `git merge`ing into an SVN branch with \n> unpushed changes.  We had to accelerate our move to git on the server, \n> and I got a lot of exercise and not much work done that month as I \n> dashed from desk to desk.\n\nthat's what I fear, because we usually are overladen of work and we\ncan't stand some slow down if it last more then 2-3 days in a row.\nIf that happen I'll be the one who will be blamed for the issue :)\n\n> Things gradually calmed down as people got more comfortable with git. \n> But I expect to be occasionally called over for a long time as people \n> learn new tricks - \"how do I, like, cherry-unpick a single commit?\"\n\nWell.. that's ok.. the problem is with things I don't know about git\nlike: what's the best way to manage binary files? how do I manage\nsubmodules? and so on... if I don't know how to properly reply to those\nquestions I'll obtain the opposite effect :)\n\nThanks for your experience,\n\nDaniele\n"},{"id":"142104","messageId":"1274543931.21346.171.camel@Luffy","threadId":"23869","inReplyTo":"m34oi1s13e.fsf@localhost.localdomain","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Daniele Segato","fromEmail":"daniele.bilug@gmail.com","sentAt":"2010-05-22T15:58:51Z","receivedAt":"2010-05-22T15:58:51Z","isPatch":false,"sender":{"key":"daniele.bilug@gmail.com","avatar":null},"body":"Il giorno ven, 21/05/2010 alle 08.54 -0700, Jakub Narebski ha scritto:\n> Daniele Segato <daniele.bilug@gmail.com> writes:\n> \n> [...]\n> > I think that to introduce git in my company I should at least go throw\n> > this 5 points:\n> \n> > 1. prepare a project management web application easy to use and\n> >    mantain (like github or gitorious for instance) on one of our\n> >    intranet servers.\n> \n> Note that while Gitorious (in Ruby), InDefero (in PHP), and Girocco\n> (with gitweb, Perl + shell script, used by http://repo.or.cz) are open\n> source, GitHub is not.  There is GitHub:FI if you want [self] hosted\n> GitHub-alike, but it is proprietary and it is not cheap.\n> \n> There is also Gerrit, a web based code review system, which runs in\n> any standard Java servlet container.\n\nThanks for the list.\nYes I know GitHub isn't Open Source, and just for this reason it can't\nbe an option, but it's features are the one I'm looking for.\nI never heard of some of the project you listed here, I'll give them a\ntry.\nDid someone worked with some of them and have a review or an opinion\nabout them?\n\n> \n> [...]\n> > Can you also tell me if you think there is some risk in migrating and\n> > what kind of difficult I could encounter in the process?\n> > For example: like any company we have a proxy and a firewall..\n> > For example: if i had to commit something working from home I connect\n> > to the Subversion via HTTPS and commit, with Git I should have ssh\n> > access which is something that I probably will not have.\n> \n> Actually with never Git you can push and pull via HTTP(S) natively,\n> thanks to git-http-backend.  With older Git you had to use HTTP as\n> \"dumb\" protocol, using HTTPS + WebDAV to push (note that for \"dumb\"\n> servers git-update-server-info must be run, e.g. via a hook).\n\nOh, that's interesting. I wasn't aware of this.\nI'll go read some doc about this new feature, thanks.\n\nDaniele\n"},{"id":"142105","messageId":"201005221806.51213.jnareb@gmail.com","threadId":"23869","inReplyTo":"1274543931.21346.171.camel@Luffy","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-05-22T16:06:50Z","receivedAt":"2010-05-22T16:06:50Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia sobota 22. maja 2010 17:58, Daniele Segato napisał:\n> Il giorno ven, 21/05/2010 alle 08.54 -0700, Jakub Narebski ha scritto:\n> > Daniele Segato <daniele.bilug@gmail.com> writes:\n> > \n> > [...]\n> > > I think that to introduce git in my company I should at least go throw\n> > > this 5 points:\n> > \n> > > 1. prepare a project management web application easy to use and\n> > >    mantain (like github or gitorious for instance) on one of our\n> > >    intranet servers.\n> > \n> > Note that while Gitorious (in Ruby), InDefero (in PHP), and Girocco\n> > (with gitweb, Perl + shell script, used by http://repo.or.cz) are open\n> > source, GitHub is not.  There is GitHub:FI if you want [self] hosted\n> > GitHub-alike, but it is proprietary and it is not cheap.\n> > \n> > There is also Gerrit, a web based code review system, which runs in\n> > any standard Java servlet container.\n> \n> Thanks for the list. [...] I never heard of some of the project you\n> listed here, I'll give them a try.\n\nhttps://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools should\nbe a good source of information about miscelanous git tools.\n\n> Did someone worked with some of them and have a review or an opinion\n> about them?\n\nThat I can't help you with.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"142110","messageId":"4BF821DF.8040300@workspacewhiz.com","threadId":"23869","inReplyTo":"1274543931.21346.171.camel@Luffy","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Joshua Jensen","fromEmail":"jjensen@workspacewhiz.com","sentAt":"2010-05-22T18:26:39Z","receivedAt":"2010-05-22T18:26:39Z","isPatch":false,"sender":{"key":"jjensen@workspacewhiz.com","avatar":"https://avatars.githubusercontent.com/u/111687?v=4"},"body":"  ----- Original Message -----\nFrom: Daniele Segato\nDate: 5/22/2010 9:58 AM\n>> There is also Gerrit, a web based code review system, which runs in\n>> any standard Java servlet container.\n> Did someone worked with some of them and have a review or an opinion\n> about them?\nI use http://redmine.org/.  It has Git support and generally works \ngreat.  There is a decent set of plug-ins for it, too.\n\nI set up Gerrit, and I really like what I see there.  Not only does it \nhave code review functionality built in, it also knows how to merge \nchanges automatically (as I understand it) when everyone buys off on the \nchange.\n\nJosh\n"},{"id":"142132","messageId":"AANLkTim8NfxY75tpHIEx1LMatWQ5P-LgCaNSeNp2KFa3@mail.gmail.com","threadId":"23869","inReplyTo":"4BF7B751.7050704@pileofstuff.org","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Lin Mac","fromEmail":"mkl0301@gmail.com","sentAt":"2010-05-23T09:12:28Z","receivedAt":"2010-05-23T09:12:28Z","isPatch":false,"sender":{"key":"mkl0301@gmail.com","avatar":null},"body":"2010/5/22 Andrew Sayers <andrew-git@pileofstuff.org>:\n> Hi Daniele,\n>\n> I'm a developer getting towards the end of introducing my company to Git.\n>  Here are some thoughts based on the (mis)steps I took.\n\nI'm a developer who had started to learn git for 1 and a half year,\nand start using git for half year. It took me 1 year to make myself\nbelieve that I am ready to use git as my daily working project.\nAlthough I also wants to push my company to use git, but I prefer to\nstart from one. I \"forced\" one of my colleague to use git -- I only\nuse git to share code with him...\n\nBWT, we use svn as well.\n\n> I found that advocating specific steps wasn't that effective - I just came\n> across as being pushy and hard to work with.  It was more effective to\n> politely show off what I could do with git-svn, and let people get jealous\n> enough to work the \"how\" out for themselves.  Here are some examples:\n>\n> I would quietly bisect a hard-to-fix bug, then say \"if it's any help, git\n> tells me it was introduced by so-and-so in revision N\".  Sometimes it was no\n> help, but sometimes it was enough to provoke the appropriate \"aha!\" for the\n> bug.\n>\n> I would nonchalantly use as many git features as I could while showing\n> people my work.  So \"here's the diff for my work... grr whitespace ... hang\n> on I'll add `-w`... anyway, these are the REAL differences...\". The fact it\n> was all in glorious technicolour went without mention.\n>\n> When we had a big merge that nobody was looking forward to, I said \"let me\n> do it!  It'll give me a chance to practice my git-fu\".\n>\n> When I used svn on somebody else's command-line, I'd blame the mistakes I\n> made on being spoiled by Git.  So \"I'll just do an `svn log`... argh no!\n>  Control-C!  Control-C!  Right, `svn log | less`... my bad, git pipes to\n> less automatically.\"\nMy colleague shows amazing insterest on \"git add -p\".\n\"see? you could decided what to add to the commit and what no to. you\ndon't have to always clean the code before you commit....\"\nWith git-svn, he started to use git since then.\n\n> Over the course of a few months, people became convinced that Git was\n> something that makes you more productive.  Our lead developer had a go with\n> git-svn for a while, before our boss decided we should all make the switch.\n>\n> I tried to make git-svn as painless as possible with some svn-like aliases\n> and a cheatsheet, which I'd be happy to upload if the list could suggest a\n> good place to put a PDF and some text.\n>\n> The move worked for a while, but it turned out that one-and-a-half git\n> experts supporting the rest of the team wasn't enough to stop people from\n> making rookie mistakes like `git merge`ing into an SVN branch with unpushed\n> changes.  We had to accelerate our move to git on the server, and I got a\n> lot of exercise and not much work done that month as I dashed from desk to\n> desk.\n>\n> Things gradually calmed down as people got more comfortable with git. But I\n> expect to be occasionally called over for a long time as people learn new\n> tricks - \"how do I, like, cherry-unpick a single commit?\"\nThat's what I'm affraid, so I started from one :p\n\nEven though, I'm often called for questions like \"how do I check out\nthis?\" \"how do I do 'svn revert')..., and I think it will last\nforever.\n\nBefore I can really start to use git, I used to joke \"git is for gods\nlike Linus, not for mortal\". Of course I don't think so now, but what\nI want to say is that git have harder learning curve than svn (at\nleast I think so). commands are sometimes confusing, and it is very\npossible that users would screw thing up if they don't pay attention\nwhen using it.\n\nFor example:\n\nIt take times to explain the difference of \"git reset\", \"git reset\nHEAD^\" and \"git reset --hard\", and \"git add <new_file>\", \"git add\n<old_file>\", and \"git add -p\" (why \"git add -p\" doesn't add my new\nfile/permission changes....blablabla).\n\nAnd my first time trying git failed because I found all my previous\ncommit are \"gone\", \"disappearred\", \"losted\". You could imaging how\nfrustrated I am. Though latter I found that my commits are not gone,\nbut dangling!! I commited on no-branch state. But that stop me from\nlearning git for some time...\n\nRecently, I used git branch \"extensively\" - I have a lot of branches,\nbranch have branches, such that one of which became a \"tree\". To\nrebase the \"tree\" to another base takes 15~20 rebase. It is\nerror-prone, and I find nothing could release me from such situation.\nI have to change my way to add branch.\n\nHave someone experienced with git would greatly reduce the effort and\ninconvenience.\n\nStarting from git-svn would be a goot starting point. If people could\nbe benefit from git-svn, switching to git wouldn't be a big problem.\n\nBest Regards,\nMac Lin\n"},{"id":"142151","messageId":"4BF94138.5000007@pileofstuff.org","threadId":"23869","inReplyTo":"1274543552.21346.166.camel@Luffy","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Andrew Sayers","fromEmail":"andrew-git@pileofstuff.org","sentAt":"2010-05-23T14:52:40Z","receivedAt":"2010-05-23T14:52:40Z","isPatch":false,"sender":{"key":"andrew-git@pileofstuff.org","avatar":null},"body":"Hi Daniele,\n\nI agree that a lead developer moving a team from graphical SVN is a\ndifferent problem.  I don't think git-gui does SVN, I couldn't work out\nhow to make TortioseGit work with SVN, and I doubt EGit will like SVN\nvery much.\n\nYou're also right that git-svn has limitations with merging and\nrebasing.  Specifically, don't use them unless you know what you're\ndoing - see `man git-svn` for more.  Git-svn is also less\nnewbie-friendly than either git or svn on its own.\n\nHaving said that, I'd still recommend you try moving a few developers to\ngit during the lifetime of your current project.  In my experience,\nthose developers most willing to try something new in the middle of a\nproject are also the ones that want to get hacking right away on a new\nproject.  Getting even one developer to start migrating now will be good\npractice for you, and will double the number of eyeballs looking at git\nissues later on.\n\nSlowing down for less than a week is a very ambitious target - I think\nwe had about 2 weeks of noticeably reduced productivity, even when I'd\ndone a lot of work to spread the pain over several months.  Starting git\nwith a new project might reduce that time a bit - for example, there's\nno chance of uncommitted work in an SVN checkout failing to make the\nswitch.  But it can be more expensive in the long-run, because you have\nto make all of your architectural decisions based on what you can\nexplain to SVN users on day one - for example, my team took about 2-3\nweeks to understand how a commit is different from a push, and why they\nshould care.  But because they understood before we made the big leap,\nwe were able decentralise our workflow as much as we needed.\n\nIf you do go via git-svn, I'd recommend you read `man git-rerere` and\nset the config option \"rerere.enabled\" to \"true\" for all users.  I\nneeded to blow away a few messy merges to fix rookie mistakes, and\n`git-rerere` would have made a painful experience much easier.\n\nEven if you go straight into git, you might think about finding/writing\nhooks to synchronise an SVN repository and a git repository.  There will\nprobably be a few people you can't switch right away - e.g. a sysadmin\nthat would need months to rewrite all his scripts, or a designer that\ndoesn't want to learn a different tool just for your team.  Providing a\nsemi-functional legacy interface for those people will let you raise the\npressure on them more gradually.\n\nI forgot to mention education in my previous post, which was actually\none of the biggest problems during the move.  I was surprised how\neveryone had such different learning styles - some wanted to learn the\ntheory then be left alone, some wanted to be told each solution at the\nmoment they faced the problem, some wanted to learn by watching how I\nworked, etc.  The only real pattern seems to be that the busier people\nare, the more they like to feel they're pulling information out of you,\nand the less receptive they are when you push information at them.  I\nmuddled through by trying to give everyone more of whatever they each\nreacted best to.\n\nThe biggest problem I had with teaching git to SVN users was something I\nstill have difficulty putting into words.  SVN users focus on branches\nas the centre of their development history, and see commits as these\nfunny little things that punctuate the progress of their branches.  But\ngit users focus on commits (or even trees) as the centre of their\nhistory, and see branches as one of many handy labels that track them.\nThe distinction is subtle, but it affects a lot of the expectations\npeople have.  For example, SVN users like to think of a commit as being\n\"on a branch\", meaning that it marks an event in the lifetime of one SVN\ndirectory.  To this day, I don't think I've really communicated why you\ncan only say a git commit is \"reachable from the tip of zero or more\nbranches\".\n\nBecause my team needed time to unlearn a lot of these SVN issues, I\ndidn't try to push much deep git tech at them early on.  A few months\ninto the move though, it's starting to seem like a better idea.  One of\nmy team-mates got me to start reading \"Version Control with Git\"\n(http://oreilly.com/catalog/9780596520137) - from what I've seen so far,\nI'd definitely recommend it to people that like book-learning and are\nready to learn git without bringing their old SVN baggage.  On the other\nhand, you can cobble the same information together from various online\nsources if you prefer (http://book.git-scm.com/ is a personal favourite).\n\n\t- Andrew Sayers\n"},{"id":"142152","messageId":"4BF9446D.7010502@pileofstuff.org","threadId":"23869","inReplyTo":"AANLkTim8NfxY75tpHIEx1LMatWQ5P-LgCaNSeNp2KFa3@mail.gmail.com","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Andrew Sayers","fromEmail":"andrew-git@pileofstuff.org","sentAt":"2010-05-23T15:06:21Z","receivedAt":"2010-05-23T15:06:21Z","isPatch":false,"sender":{"key":"andrew-git@pileofstuff.org","avatar":null},"body":"On 23/05/10 10:11, Lin Mac wrote:\n> My colleague shows amazing insterest on \"git add -p\".\n> \"see? you could decided what to add to the commit and what no to. you\n> don't have to always clean the code before you commit....\"\n> With git-svn, he started to use git since then.\n\nI had a similar experience - a colleague with a habit of making huge\ncommits happily cleaned up his act when he was shown this.  More\ngenerally, it seems like everyone reacts to the list of git features\nwith \"that one's weird, I don't care about that one, that one's\nirritating, WHERE HAS THIS BEEN ALL MY LIFE!, don't care about that one,\nthat one doesn't make sense...\".  A major part of selling people on git\nis finding the one thing that they each immediately love.\n\n\t- Andrew\n"},{"id":"142169","messageId":"1274654766.25555.25.camel@Luffy","threadId":"23869","inReplyTo":"AANLkTilIihNTDPZ5NIKUzsPEZ2Gpusm-10FCBVifvNuw@mail.gmail.com","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Daniele Segato","fromEmail":"daniele.bilug@gmail.com","sentAt":"2010-05-23T22:46:06Z","receivedAt":"2010-05-23T22:46:06Z","isPatch":false,"sender":{"key":"daniele.bilug@gmail.com","avatar":null},"body":"Hi David,\nI'm quoting all your email with no cleaning here because I think you did\nnot included the git mailing list as a mistake.\n\nIl giorno dom, 23/05/2010 alle 22.09 +0200, David Bainbridge ha scritto:\n> Hi Daniele,\n> \n> On 21 May 2010 16:55, Daniele Segato <daniele.bilug@gmail.com> wrote:\n> > I work as a Developer (mainly Java and web applications) and I'd like\n> > to introduce my company to the use of Git.\n> \n> This is a trend that I am seeing in the company I work for too.\n> \n> > There are, more or less, 30 developers working in different projects\n> > from junior to senior developers.\n> \n> > We use Subversion as versioning system.\n> >\n> > The developers are used to work with Eclipse (an open source IDE) that\n> > happen to have a Subversion plugin and they all works on Windows\n> > platform.\n> > I'm the only one who work on a Linux box and use git-svn from command\n> > line as a front end to Subversion.\n> \n> So you are in a minority ... it's useful to recognise this. Others in\n> your company may not share your views.\n\nI KNOW other will not share my view. Another team leader with more\nexperience then me already told me that \"moving to something different\nof subversion is of no interest to him because he don't want to learn\nsomething new\"[1]. This happened during a random chit-chat when I\ncasually asked: \"what would you think about moving from Subversion to\nsomething more advanced?\"\nThe topic dropped suddenly after it, I did not pushed it further :)\n\n> > I already know of (some of) the advantage of using git, but I'm also\n> > aware that it's not that easy to change other people mind on what they\n> > used for years.\n> \n> Not only that - it depends who decided to use Subversion and why. Was\n> it a management decision, or was the decision made entirely by\n> developers?\n\nI think that the decision has been made a lot of time ago without any\nparticular reasons. Probably that just was the more diffused versioning\nsystem, the one used and learned by almost all the developers around\nhere. (aka: you don't have to teach it to new employers, they usually\nalready know)\n\n> Is Subversion used only during development or do you maintain the\n> products in Subversion? In other words, is Subversion seen as a secure\n> central repository for the company's intellectual property? If so,\n> they may not take kindly to a DVCS unless it is deployed with some\n> degree of centralization.\n\nBoth development and maintenance. Every developer signed an agreement to\nnot give any company sensitivity information away without the\nauthorization of the company itself, so I don't see any particular\ndifference in security between Git and Subversion. May be I missed the\npoint here anyway.\n\n> Do your products have a short life time (less than a year) or do they\n> have to be maintained over several years? If it is over several years\n> then Git and Svn may also have to co-exist in the company for that\n> time, and people may have to use both depending on what they are\n> working on.\n\nAgain: both short and long life time projects.. I know they will have to\nco-exist but I think that if the company get used to git will not go\nback to subversion as I wouldn't unless given with no choice.\n\n> Are there any security issues that need to be addressed? - especially\n> if everyone is working on laptops and taking them home, or traveling\n> with them.\n\nEverybody work on laptop, but I don't think I get the issue here: be in\ndanger of someone stealing source code? Doesn't this have the same\nsecurity issue with subversion? (but the fact that with git you get all\nthe repository and not just a single version).\n\n> I guess I am saying that you need to look at the extent to which the\n> COMPANY is dependent on Subversion. This will affect your decision\n> about who to talk to about migration - and who you will need to\n> convince.\n\nUsually in my company new technology comes from the developers\nthemselves, they have to promote and propose the idea themselves.\nManagers don't care how you do thing technically. So if I really want to\nintroduce git I'll had to do it in my spare time: building up the\ninfrastructure to made migration easier as possible, be sure to be able\nto handle all the issue that I can encounter and then begin to made my\nteam work with git.\nAfter that I can show my manager that I increased the productivity and\nthat could made them decide to migrate the other teams too.\n\n> All of which is aimed at item 4 in your list.\n> \n> > 4. give my managers some reason to migrate/begin to use Git instead of\n> > Subversion\n> \n> Training, migration and so on will take time and therefore cost money.\n> Yes, you can do it without management support but it will be a lot\n> easier if you do have their support. Get this wrong and you may be\n> seen by management as putting development at risk - and with only 30\n> developers, they may see this as putting the company itself at risk.\n\nI had to *start* it without the management support. And, to avoid the\nrisk of being seen as a risk I had to do this in my spare time. :)\n\n> In the end the company has to ship products to make a profit, so\n> focussing on that always helps :-) In small companies 'the management'\n> may be the shareholders too!\n\nYes, that's the harder part.. I can see the benefit of using git for a\ndeveloper but I can't see the benefit for my manager.\nProductivity is hard to quantify.\n\n> This is an interesting topic that I guess affects more than a few of\n> us that subscribe to this list.\n> \n> Also, I must admit that I reacted to the way in which you expressed\n> the question ... What's the best way to MAKE my company migrate to\n> Git? This has a very evangelical tone to it, so I would tend to\n> express this in other terms when discussing it in your company.\n> \n> Answering your question is more about people than the tool itself.\n\nProbably you are right, but I wrote here exactly to ask for advice on\nthe best way to propose git.\nI know that the \"evangelist\" method will not lead me anyway within the\ncompany, I'd like to have some suggestion on that :)\n\n> \n> Hope this helps. And do keep us updated ... this is interesting!\n\nI'll do.\n\n> Regards\n> \n> David Bainbridge\n\n\nThanks David for your suggestions.\n\nRegards,\nDaniele Segato\n\n[1] a note: this may sound like \"I don't care about new technology\".\nThat's not exactly the case, you can read it like this: \"I already have\na lot of thing to do (too much thing) and I can't add anything else\nwithout going crazy\".\n"},{"id":"142210","messageId":"AANLkTilhVbdaZgE4NINrl4RA6ArkeMstyFdnq9eD4o8B@mail.gmail.com","threadId":"23869","inReplyTo":"4BF94138.5000007@pileofstuff.org","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Daniele Segato","fromEmail":"daniele.bilug@gmail.com","sentAt":"2010-05-24T17:37:14Z","receivedAt":"2010-05-24T17:37:14Z","isPatch":false,"sender":{"key":"daniele.bilug@gmail.com","avatar":null},"body":"On Sun, May 23, 2010 at 4:52 PM, Andrew Sayers\n<andrew-git@pileofstuff.org> wrote:\n> I agree that a lead developer moving a team from graphical SVN is a\n> different problem.  I don't think git-gui does SVN, I couldn't work out\n> how to make TortioseGit work with SVN, and I doubt EGit will like SVN\n> very much.\n\nEGit do not work with git-svn, it probably work just fine with \"pure\" git tough.\nI've seen TortoiseGit, it work very well but I found it somewhat more\ndifficult then the command line:\nprobably because I don't know where to find the command i daily use on git.\nI extensively use git grep and probably there isn't anything like it\nin TortoiseGit.\n\n> You're also right that git-svn has limitations with merging and\n> rebasing.  Specifically, don't use them unless you know what you're\n> doing - see `man git-svn` for more.  Git-svn is also less\n> newbie-friendly than either git or svn on its own.\n\nYes, that's why I'd like to skip git-svn and go directly with git,\nunless I know the people I'm teaching to can\nhandle it.\n\n> Having said that, I'd still recommend you try moving a few developers to\n> git during the lifetime of your current project.  In my experience,\n> those developers most willing to try something new in the middle of a\n> project are also the ones that want to get hacking right away on a new\n> project.  Getting even one developer to start migrating now will be good\n> practice for you, and will double the number of eyeballs looking at git\n> issues later on.\n\nYeah, there is one developer tired of Subversion that asked me to\nteach him git(-svn).\nHe's not in my team but I think it's a starting point :)\n\n> Slowing down for less than a week is a very ambitious target - I think\n> we had about 2 weeks of noticeably reduced productivity, even when I'd\n> done a lot of work to spread the pain over several months.  Starting git\n> with a new project might reduce that time a bit - for example, there's\n> no chance of uncommitted work in an SVN checkout failing to make the\n> switch.  But it can be more expensive in the long-run, because you have\n> to make all of your architectural decisions based on what you can\n> explain to SVN users on day one - for example, my team took about 2-3\n> weeks to understand how a commit is different from a push, and why they\n> should care.  But because they understood before we made the big leap,\n> we were able decentralise our workflow as much as we needed.\n\n\nProbably it will be a svn-like architecture from the beginning, I'll\nnot dare to move it any\nfurther until I know that developers are ready to handle it properly :)\nI'm not sure myself I can manage a workflow different from subversion\n(1 main server and N developers\npushing to it) because I never did anything different.\n\n\n> If you do go via git-svn, I'd recommend you read `man git-rerere` and\n> set the config option \"rerere.enabled\" to \"true\" for all users.  I\n> needed to blow away a few messy merges to fix rookie mistakes, and\n> `git-rerere` would have made a painful experience much easier.\n\nI did not know about this.. That's really interesting, I just enabled\nit in my local repo.\nThanks for the hint!\n\n> Even if you go straight into git, you might think about finding/writing\n> hooks to synchronise an SVN repository and a git repository.  There will\n> probably be a few people you can't switch right away - e.g. a sysadmin\n> that would need months to rewrite all his scripts, or a designer that\n> doesn't want to learn a different tool just for your team.  Providing a\n> semi-functional legacy interface for those people will let you raise the\n> pressure on them more gradually.\n\nSysadmins shouldn't be a problem, we don't have sysadmins here and if\nthe custumer\nrequire us to use his own versioning system we can't push them to git,\nso I think that wouldn't be\na proble for us. But that's a good point.\n\n> I forgot to mention education in my previous post, which was actually\n> one of the biggest problems during the move.  I was surprised how\n> everyone had such different learning styles - some wanted to learn the\n> theory then be left alone, some wanted to be told each solution at the\n> moment they faced the problem, some wanted to learn by watching how I\n> worked, etc.  The only real pattern seems to be that the busier people\n> are, the more they like to feel they're pulling information out of you,\n> and the less receptive they are when you push information at them.  I\n> muddled through by trying to give everyone more of whatever they each\n> reacted best to.\n\nThanks, I'll keep that in mind when I'll face the big switch.\n\n\n> Because my team needed time to unlearn a lot of these SVN issues, I\n> didn't try to push much deep git tech at them early on.  A few months\n> into the move though, it's starting to seem like a better idea.  One of\n> my team-mates got me to start reading \"Version Control with Git\"\n> (http://oreilly.com/catalog/9780596520137) - from what I've seen so far,\n> I'd definitely recommend it to people that like book-learning and are\n> ready to learn git without bringing their old SVN baggage.  On the other\n> hand, you can cobble the same information together from various online\n> sources if you prefer (http://book.git-scm.com/ is a personal favourite).\n\n\nThanks about the book suggestion, I'll give them both a try!\n\nRegards,\nDaniele Segato\n"},{"id":"142250","messageId":"4BFB7F7F.5090407@drmicha.warpmail.net","threadId":"23869","inReplyTo":"4BF7B751.7050704@pileofstuff.org","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-05-25T07:42:55Z","receivedAt":"2010-05-25T07:42:55Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Andrew Sayers venit, vidit, dixit 22.05.2010 12:52:\n> Hi Daniele,\n> \n> I'm a developer getting towards the end of introducing my company to \n> Git.  Here are some thoughts based on the (mis)steps I took.\n> \n> \n> I found that advocating specific steps wasn't that effective - I just \n> came across as being pushy and hard to work with.  It was more effective \n> to politely show off what I could do with git-svn, and let people get \n> jealous enough to work the \"how\" out for themselves.  Here are some \n> examples:\n> \n> I would quietly bisect a hard-to-fix bug, then say \"if it's any help, \n> git tells me it was introduced by so-and-so in revision N\".  Sometimes \n> it was no help, but sometimes it was enough to provoke the appropriate \n> \"aha!\" for the bug.\n> \n> I would nonchalantly use as many git features as I could while showing \n> people my work.  So \"here's the diff for my work... grr whitespace ... \n> hang on I'll add `-w`... anyway, these are the REAL differences...\". The \n> fact it was all in glorious technicolour went without mention.\n> \n> When we had a big merge that nobody was looking forward to, I said \"let \n> me do it!  It'll give me a chance to practice my git-fu\".\n> \n> When I used svn on somebody else's command-line, I'd blame the mistakes \n> I made on being spoiled by Git.  So \"I'll just do an `svn log`... argh \n> no!  Control-C!  Control-C!  Right, `svn log | less`... my bad, git \n> pipes to less automatically.\"\n> \n> \n> Over the course of a few months, people became convinced that Git was \n> something that makes you more productive.  Our lead developer had a go \n> with git-svn for a while, before our boss decided we should all make the \n> switch.\n> \n> I tried to make git-svn as painless as possible with some svn-like \n> aliases and a cheatsheet, which I'd be happy to upload if the list could \n> suggest a good place to put a PDF and some text.\n\nFeel free to contribute to the Git Wiki maybe at\n\nhttps://git.wiki.kernel.org/index.php/GitDocumentation\n\nin the \"User contributed Documentation\" section.\n\nMichael\n"},{"id":"142620","messageId":"4C041656.7000008@pileofstuff.org","threadId":"23869","inReplyTo":"4BFB7F7F.5090407@drmicha.warpmail.net","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Andrew Sayers","fromEmail":"andrew-git@pileofstuff.org","sentAt":"2010-05-31T20:04:38Z","receivedAt":"2010-05-31T20:04:38Z","isPatch":false,"sender":{"key":"andrew-git@pileofstuff.org","avatar":null},"body":"On 25/05/10 08:42, Michael J Gruber wrote:\n> \n> Feel free to contribute to the Git Wiki maybe at\n> \n> https://git.wiki.kernel.org/index.php/GitDocumentation\n> \n> in the \"User contributed Documentation\" section.\n> \n> Michael\n> \n\nThanks for the hint - this turned into rather more than just uploading a\nPDF, and I've now finished a complete write-up here:\n\n\thttps://git.wiki.kernel.org/index.php/SvnMigration\n\nThe \"User contributed Documentation\" section seems to be mostly off-wiki\nlinks, so I added a link from \"Documentation on this Wiki\" - I hope\nthat's ok.\n\n\t- Andrew\n"},{"id":"142650","messageId":"4C04A895.6030606@drmicha.warpmail.net","threadId":"23869","inReplyTo":"4C041656.7000008@pileofstuff.org","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-06-01T06:28:37Z","receivedAt":"2010-06-01T06:28:37Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Andrew Sayers venit, vidit, dixit 31.05.2010 22:04:\n> On 25/05/10 08:42, Michael J Gruber wrote:\n>>\n>> Feel free to contribute to the Git Wiki maybe at\n>>\n>> https://git.wiki.kernel.org/index.php/GitDocumentation\n>>\n>> in the \"User contributed Documentation\" section.\n>>\n>> Michael\n>>\n> \n> Thanks for the hint - this turned into rather more than just uploading a\n> PDF, and I've now finished a complete write-up here:\n> \n> \thttps://git.wiki.kernel.org/index.php/SvnMigration\n\nThanks a lot for your work!\n\n> \n> The \"User contributed Documentation\" section seems to be mostly off-wiki\n> links, so I added a link from \"Documentation on this Wiki\" - I hope\n> that's ok.\n\nAbsolutely. \"User contributed\" would have been the place for a (link to\nthe pdf), and \"Doc. on\" is the right place your new Wiki page.\n\nThanks again,\nMichael\n"},{"id":"142702","messageId":"AANLkTinO_Z-1myhT-0TBIjELiEd4H-NnESs-AjTIpEf9@mail.gmail.com","threadId":"23869","inReplyTo":"4C041656.7000008@pileofstuff.org","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Daniele Segato","fromEmail":"daniele.bilug@gmail.com","sentAt":"2010-06-01T16:00:54Z","receivedAt":"2010-06-01T16:00:54Z","isPatch":false,"sender":{"key":"daniele.bilug@gmail.com","avatar":null},"body":"On Mon, May 31, 2010 at 10:04 PM, Andrew Sayers\n<andrew-git@pileofstuff.org> wrote:\n> On 25/05/10 08:42, Michael J Gruber wrote:\n>>\n>> Feel free to contribute to the Git Wiki maybe at\n>>\n>> https://git.wiki.kernel.org/index.php/GitDocumentation\n>>\n>> in the \"User contributed Documentation\" section.\n>>\n>> Michael\n>>\n>\n> Thanks for the hint - this turned into rather more than just uploading a\n> PDF, and I've now finished a complete write-up here:\n>\n>        https://git.wiki.kernel.org/index.php/SvnMigration\n\n\nThat's a great job!\n\nI want to point out some difficulties I encountered switching from\nSubversion to Git-SVN.\nI'd like to discuss them here before, eventually, contributing them to\nthat page.\n\n\n= Empty directories =\nGit do not track directories, it tracks content. That means you'll not\nget/commit empty directory in your\nworking tree.\nSometimes empty directory may be needed by some fancy script or\nexternal software you use with your\nproject (example, ANT).\n\nDevelopers should be aware of this: if they really need to create an\nempty directory they can both\ncreate it through subversion both create a \"dummy\" file in the\ndirectory and commit it, if that's an option.\n\n\n= Subversion ignore =\nYou can't control subversion ignores from git-svn. And git-svn do not\nautomatically synchronize with the\nsubversion ignores. The team should be aware of these to avoid issues.\n\n\n= Local patch =\nMost subversion user keeps some modified files in their local checkout\nnever committing it remotely.\nThis may be handy for some situation where you want to enable some\ndebug-specific feature or whatever you need.\nWith Git, if the file is remotely tracked (with Subversion you'll say\n\"already committed\") you can't keep a file like that:\nit will prevent you from \"pushing\" files to the remote repository or\nchecking out other local/remote branches.\nYou'll had to \"stash\" your patch and re-apply it later.\n\n= local/remote branches =\nGit-svn branches \"track\" the remote branches by adding a string in\neach commit you \"git svn dcommit\" on\nsubversion repository. You can have many local branches tracking the\nsame remote subversion branch.\nTo start to track a new remote branch you have to \"git checkout -b\nlocalBranchName remoteBranchName\",\nwhich is not very user friendly :)\n\nYou also can't create new Subversion branches or tags with git-svn,\nyou'll had to use subversion directly for that.\n\n\n\nFeel free to correct me or better describe those issue with a\nbetter/more friendly english.\nFeel also free to add to this list.\n\n\nRegards,\nDaniele Segato\n"},{"id":"142704","messageId":"1533278916.20100601231415@yandex.ru","threadId":"23869","inReplyTo":"AANLkTinO_Z-1myhT-0TBIjELiEd4H-NnESs-AjTIpEf9@mail.gmail.com","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Alexander Iljin","fromEmail":"ajsoft@yandex.ru","sentAt":"2010-06-01T16:14:15Z","receivedAt":"2010-06-01T16:14:15Z","isPatch":false,"sender":{"key":"ajsoft@yandex.ru","avatar":"https://gravatar.com/avatar/5d53b714db7aaf3add180e650b6cbcfc17cd4ca0f29981ad97222e969a24bebb?d=mp&s=160"},"body":"Hello!\n\nDS> You also can't create new Subversion branches or tags with git-svn,\nDS> you'll had to use subversion directly for that.\n\n  Another point: you can't contribute to branches via git-svn, you can\n  only commit to trunk. It is easy to be confused if you've created a\n  feature branch in Git. If you then want to git-svn dcommit a\n  half-done work, you will mess up the trunk.\n\n\n---=====---\n Alexander\n"},{"id":"142705","messageId":"AANLkTimenYsHEhTO3wqW_BRMMKZbA6ExLOOytaopGLjh@mail.gmail.com","threadId":"23869","inReplyTo":"AANLkTinO_Z-1myhT-0TBIjELiEd4H-NnESs-AjTIpEf9@mail.gmail.com","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-06-01T16:25:33Z","receivedAt":"2010-06-01T16:25:33Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Tue, Jun 1, 2010 at 6:00 PM, Daniele Segato <daniele.bilug@gmail.com> wrote:\n> On Mon, May 31, 2010 at 10:04 PM, Andrew Sayers\n> <andrew-git@pileofstuff.org> wrote:\n>> On 25/05/10 08:42, Michael J Gruber wrote:\n>>>\n>>> Feel free to contribute to the Git Wiki maybe at\n>>>\n>>> https://git.wiki.kernel.org/index.php/GitDocumentation\n>>>\n>>> in the \"User contributed Documentation\" section.\n>>>\n>>> Michael\n>>>\n>>\n>> Thanks for the hint - this turned into rather more than just uploading a\n>> PDF, and I've now finished a complete write-up here:\n>>\n>>        https://git.wiki.kernel.org/index.php/SvnMigration\n>\n>\n> That's a great job!\n>\n> I want to point out some difficulties I encountered switching from\n> Subversion to Git-SVN.\n> I'd like to discuss them here before, eventually, contributing them to\n> that page.\n>\n>\n> = Empty directories =\n> Git do not track directories, it tracks content. That means you'll not\n> get/commit empty directory in your\n> working tree.\n> Sometimes empty directory may be needed by some fancy script or\n> external software you use with your\n> project (example, ANT).\n>\n> Developers should be aware of this: if they really need to create an\n> empty directory they can both\n> create it through subversion both create a \"dummy\" file in the\n> directory and commit it, if that's an option.\n>\n\nThis has been solved in recent versions of git: git-svn creates the\nempty directories when you check out. It might not be 100% robust (I'm\nnot saying it isn't robust, I'm saying I don't know if it is), but it\nworks for my setup.\n\n> You also can't create new Subversion branches or tags with git-svn,\n> you'll had to use subversion directly for that.\n>\n\nIncorrect. git-svn have sub-commands called 'branch' and 'tag' for this purpose.\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"142706","messageId":"AANLkTinLoLr2adyLpVSUHkh0_6heaCNsnHWyzrESDLPu@mail.gmail.com","threadId":"23869","inReplyTo":"AANLkTimenYsHEhTO3wqW_BRMMKZbA6ExLOOytaopGLjh@mail.gmail.com","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Daniele Segato","fromEmail":"daniele.bilug@gmail.com","sentAt":"2010-06-01T16:36:13Z","receivedAt":"2010-06-01T16:36:13Z","isPatch":false,"sender":{"key":"daniele.bilug@gmail.com","avatar":null},"body":"On Tue, Jun 1, 2010 at 6:25 PM, Erik Faye-Lund <kusmabite@googlemail.com> wrote:\n>> = Empty directories =\n\n> This has been solved in recent versions of git: git-svn creates the\n> empty directories when you check out. It might not be 100% robust (I'm\n> not saying it isn't robust, I'm saying I don't know if it is), but it\n> works for my setup.\n\nOh, i see, i'm using an old version of git and I did not noticed this.\n\n>> You also can't create new Subversion branches or tags with git-svn,\n>> you'll had to use subversion directly for that.\n>>\n>\n> Incorrect. git-svn have sub-commands called 'branch' and 'tag' for this purpose.\n\nI wasn't aware of this command. it is strange I did not notice them before.\nBut thanks for the correction!\n\nRegards,\nDaniele Segato\n"},{"id":"142711","messageId":"AANLkTimnQJmctLU1LmT1x3KhB84J2Wrqsa8Nfo5vVDLI@mail.gmail.com","threadId":"23869","inReplyTo":"1533278916.20100601231415@yandex.ru","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Daniele Segato","fromEmail":"daniele.bilug@gmail.com","sentAt":"2010-06-01T17:16:19Z","receivedAt":"2010-06-01T17:16:19Z","isPatch":false,"sender":{"key":"daniele.bilug@gmail.com","avatar":null},"body":"2010/6/1 Alexander Iljin <ajsoft@yandex.ru>:\n> Hello!\n>\n> DS> You also can't create new Subversion branches or tags with git-svn,\n\nI've been corrected on this: git svn tag and git svn branch are there\nfor that purpose.\n\n>  Another point: you can't contribute to branches via git-svn, you can\n>  only commit to trunk. It is easy to be confused if you've created a\n>  feature branch in Git. If you then want to git-svn dcommit a\n>  half-done work, you will mess up the trunk.\n\nthat's not correct\n\nYou can contribute to any subversion branch, but you have to do it\nwith a local branch tracking the\nremote one\n\nsay you are on \"master\" which track remote svn \"trunk\" and you want to\ncontribute to remote branch \"v1.x\"\n\nyou can do this:\n\ngit checkout -b myBranch-v-1-x v1.x\n\nit will checkout the remote v1.x creating a new label \"myBranch-v-1-x\"\nfor tracking it.\nyou can then work on myBranch-v-1-x as usual, when you'll git svn\ndcommit from there you'll commit on the remote v1.x branch.\n\n\nbut you have to be careful with cherry-picking.\n\nif you want to cherry pick a comment on trunk to commit it on branch\nv1.x you'll have to amend it removing the line:\n\ngit-svn-id: https://your-svn-url/repos/trunk@1234 a123123....\n\nor you'll not be able to commit on the remote v1.x branch.\n\nI created a local alias for cherry-picking an a safe way for subversion:\n\n[from alias section in my .gitconfig]\n\ncherry-pick-svn =  !GIT_EDITOR='sed -i /^git-svn-id:/d' git cherry-pick -e\n\nwhich do a normal cherry-pick automatically editing the commit to\nremove that line.\n\nmay be this could be added to the svn alias list?\n\nRegards,\nDaniele Segato\n"},{"id":"142716","messageId":"1785192885.20100602004519@yandex.ru","threadId":"23869","inReplyTo":"AANLkTimnQJmctLU1LmT1x3KhB84J2Wrqsa8Nfo5vVDLI@mail.gmail.com","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Alexander Iljin","fromEmail":"ajsoft@yandex.ru","sentAt":"2010-06-01T17:45:19Z","receivedAt":"2010-06-01T17:45:19Z","isPatch":false,"sender":{"key":"ajsoft@yandex.ru","avatar":"https://gravatar.com/avatar/5d53b714db7aaf3add180e650b6cbcfc17cd4ca0f29981ad97222e969a24bebb?d=mp&s=160"},"body":"Hello!\n\nDS> You can contribute to any subversion branch, but you have to do it\nDS> with a local branch tracking the\nDS> remote one\n\nDS> say you are on \"master\" which track remote svn \"trunk\" and you want to\nDS> contribute to remote branch \"v1.x\"\n\nDS> you can do this:\n\n  Thank you for the correction. I branched off the master, and then\n  worked on both master and the feature branch. When I tried to\n  dcommit, I could either push one or the other set of changes,\n  whichever was currently checked out in Git. Glad to know there IS a\n  way to do this properly. Still, a possible point to make in the\n  Wiki.\n\n---=====---\n Alexander\n"},{"id":"142726","messageId":"4C0577D1.6030805@pileofstuff.org","threadId":"23869","inReplyTo":"AANLkTinO_Z-1myhT-0TBIjELiEd4H-NnESs-AjTIpEf9@mail.gmail.com","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Andrew Sayers","fromEmail":"andrew-git@pileofstuff.org","sentAt":"2010-06-01T21:12:49Z","receivedAt":"2010-06-01T21:12:49Z","isPatch":false,"sender":{"key":"andrew-git@pileofstuff.org","avatar":null},"body":"I certainly think a \"Git Traps for the Unwary\" section would go well at\nthe bottom of the page.  My life would have been much easier if I could\nhave shown people a page where they could find ways to fix the things\nI'd wrongly dismissed as non-problems.\n\nI definitely agree about empty directories - even with Erik's point\nabout git-svn handling these, it's an issue people will face when they\ntransfer to git proper.\n\nI'd suggest discussing svn:ignore as part of the wider topic of git's\nnon-support of SVN properties.  There are probably SVN teams out there\nwith elaborate sets of properties to migrate, and svn:ignore is a nice\nhook to hang that discussion on without sending everyone else to sleep.\n\nI agree that local/remote branches are worth discussing in more detail,\nalthough I'm not sure how to explain it in SVN-friendly terms beyond\n\"this will seem weird at first, but will make sense eventually\".  In\nfact this is definitely a trap for the unwary, because the move from\ndirectory-branches to label-branches tripped our migration up when we\nhad to rewrite tools that expected a \"trunk\" directory that was\nguaranteed to have mainline code.\n\nI think it's also worth mentioning local/remote commits, as it's quite\neasy for people to commit and forget to push.\n\nFinally, I agree that stash is certainly worth a mention - I'd also\nsuggest explaining how it's useful with `git svn rebase` and with\nswitching branches.  So I'd recommend putting it after both of those\nsections.\n\n\nI hope to have some writing time available this weekend, though that\ncould easily not happen.  So if someone else wants to have a crack at\nit, be my guest :)\n\n\t- Andrew\n"},{"id":"142768","messageId":"20100602051907.GA19934@inner.home.ulmdo.de","threadId":"23869","inReplyTo":"4C0577D1.6030805@pileofstuff.org","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Andreas Krey","fromEmail":"a.krey@gmx.de","sentAt":"2010-06-02T05:19:07Z","receivedAt":"2010-06-02T05:19:07Z","isPatch":false,"sender":{"key":"a.krey@gmx.de","avatar":"https://avatars.githubusercontent.com/u/37810?v=4"},"body":"On Tue, 01 Jun 2010 22:12:49 +0000, Andrew Sayers wrote:\n...\n> I think it's also worth mentioning local/remote commits, as it's quite\n> easy for people to commit and forget to push.\n\nI found (for myself) 'gitk --all' making it lots easier to see the light\nin these regards. (Missing such a thing for svn sorely.) Doing a fetch,\npressing F5 and seeing the remote branches move. Or diverge.\n\nAndreas\n"},{"id":"142791","messageId":"4C06050C.2040505@drmicha.warpmail.net","threadId":"23869","inReplyTo":"AANLkTinO_Z-1myhT-0TBIjELiEd4H-NnESs-AjTIpEf9@mail.gmail.com","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2010-06-02T07:15:24Z","receivedAt":"2010-06-02T07:15:24Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Daniele Segato venit, vidit, dixit 01.06.2010 18:00:\n> On Mon, May 31, 2010 at 10:04 PM, Andrew Sayers\n> <andrew-git@pileofstuff.org> wrote:\n>> On 25/05/10 08:42, Michael J Gruber wrote:\n>>>\n>>> Feel free to contribute to the Git Wiki maybe at\n>>>\n>>> https://git.wiki.kernel.org/index.php/GitDocumentation\n>>>\n>>> in the \"User contributed Documentation\" section.\n>>>\n>>> Michael\n>>>\n>>\n>> Thanks for the hint - this turned into rather more than just uploading a\n>> PDF, and I've now finished a complete write-up here:\n>>\n>>        https://git.wiki.kernel.org/index.php/SvnMigration\n> \n> \n> That's a great job!\n> \n> I want to point out some difficulties I encountered switching from\n> Subversion to Git-SVN.\n> I'd like to discuss them here before, eventually, contributing them to\n> that page.\n\nAndrew's main thrust is how to migrate a team, not how to migrate a code\nbase, and even less about the technical differences between svn and git.\nAnd that makes it especially valuable.\n\nI'd suggest not mixing these things. Andrew's page fills a gap about the\nsocial aspects of the migration, and does so very well. He mentions very\nfew technical aspects, only those which you need to take into account\nfor planning out your team migration, i.e. relevant to advocacy, change\nof philosophy, avoiding typical pitfalls.\n\nThere's already a score of pages about technical differences between git\nand svn. So, please, add your technical aspects to those (or improve and\ncorrect them), and/or link to corresponding or new pages from\nSvnMigration under \"See Also\".\n\nIf you have additions to the migration aspects feel free to add them to\nSvnMigration, of course. I know there's no sharp line but I don't want\nto see a can of technical worms opened on that page :)\n\nCheers,\nMichael\n"},{"id":"142830","messageId":"AANLkTikUsYOvB26DI2IWi6mghFM6Fj2bVuasaSKUfXba@mail.gmail.com","threadId":"23869","inReplyTo":"AANLkTinO_Z-1myhT-0TBIjELiEd4H-NnESs-AjTIpEf9@mail.gmail.com","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Sylvain Rabot","fromEmail":"sylvain@abstraction.fr","sentAt":"2010-06-02T16:01:04Z","receivedAt":"2010-06-02T16:01:04Z","isPatch":false,"sender":{"key":"sylvain@abstraction.fr","avatar":"https://avatars.githubusercontent.com/u/153052?v=4"},"body":"On Tue, Jun 1, 2010 at 18:00, Daniele Segato <daniele.bilug@gmail.com> wrote:\n> On Mon, May 31, 2010 at 10:04 PM, Andrew Sayers\n> <andrew-git@pileofstuff.org> wrote:\n>> On 25/05/10 08:42, Michael J Gruber wrote:\n>>>\n>>> Feel free to contribute to the Git Wiki maybe at\n>>>\n>>> https://git.wiki.kernel.org/index.php/GitDocumentation\n>>>\n>>> in the \"User contributed Documentation\" section.\n>>>\n>>> Michael\n>>>\n>>\n>> Thanks for the hint - this turned into rather more than just uploading a\n>> PDF, and I've now finished a complete write-up here:\n>>\n>>        https://git.wiki.kernel.org/index.php/SvnMigration\n>\n>\n> That's a great job!\n>\n> I want to point out some difficulties I encountered switching from\n> Subversion to Git-SVN.\n> I'd like to discuss them here before, eventually, contributing them to\n> that page.\n>\n>\n> = Empty directories =\n> Git do not track directories, it tracks content. That means you'll not\n> get/commit empty directory in your\n> working tree.\n> Sometimes empty directory may be needed by some fancy script or\n> external software you use with your\n> project (example, ANT).\n>\n> Developers should be aware of this: if they really need to create an\n> empty directory they can both\n> create it through subversion both create a \"dummy\" file in the\n> directory and commit it, if that's an option.\n>\n>\n> = Subversion ignore =\n> You can't control subversion ignores from git-svn. And git-svn do not\n> automatically synchronize with the\n> subversion ignores. The team should be aware of these to avoid issues.\n>\n>\n> = Local patch =\n> Most subversion user keeps some modified files in their local checkout\n> never committing it remotely.\n> This may be handy for some situation where you want to enable some\n> debug-specific feature or whatever you need.\n> With Git, if the file is remotely tracked (with Subversion you'll say\n> \"already committed\") you can't keep a file like that:\n> it will prevent you from \"pushing\" files to the remote repository or\n> checking out other local/remote branches.\n> You'll had to \"stash\" your patch and re-apply it later.\n\nAFAIK you're not obliged to have a clean working tree to push.\nIf you want to keep patches on a branch you push regularly, creating a\nnew branch and committing on it is more appropriate, keeping the\npatches as stash is not very handy.\nPersonally I only use stash when I'm on the middle of something and I\nhave to checkout another branch to check something.\n\n>\n> = local/remote branches =\n> Git-svn branches \"track\" the remote branches by adding a string in\n> each commit you \"git svn dcommit\" on\n> subversion repository. You can have many local branches tracking the\n> same remote subversion branch.\n> To start to track a new remote branch you have to \"git checkout -b\n> localBranchName remoteBranchName\",\n> which is not very user friendly :)\n>\n> You also can't create new Subversion branches or tags with git-svn,\n> you'll had to use subversion directly for that.\n>\n>\n>\n> Feel free to correct me or better describe those issue with a\n> better/more friendly english.\n> Feel also free to add to this list.\n>\n>\n> Regards,\n> Daniele Segato\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n\n\n\n-- \nSylvain\n"},{"id":"143063","messageId":"4C0AC140.6090808@pileofstuff.org","threadId":"23869","inReplyTo":"4C06050C.2040505@drmicha.warpmail.net","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Andrew Sayers","fromEmail":"andrew-git@pileofstuff.org","sentAt":"2010-06-05T21:27:28Z","receivedAt":"2010-06-05T21:27:28Z","isPatch":false,"sender":{"key":"andrew-git@pileofstuff.org","avatar":null},"body":"On 02/06/10 08:15, Michael J Gruber wrote:\n> \n> Andrew's main thrust is how to migrate a team, not how to migrate a code\n> base, and even less about the technical differences between svn and git.\n> And that makes it especially valuable.\n\nI'm glad you like it, and I've now finished version 2.  I think I've\ncovered most of the points raised in this thread without getting too far\ninto technical issues that I agree belong on a different page.\n\nAs well as a few typographic upgrades, I've added some text to the \"Git\nas an SVN client\" section - warnings for the issues that Daniele\nmentioned, and explaining git issues to SVN users.  I remember now the\nmental anguish I went through trying to explain what a local index is,\nso I thought I'd save other people the bother :)\n\nAs promised, I've also added a \"traps for the unwary\" section, although\nI'm quite tempted to make it a page on its own.  The intended audience\nand writing style is necessarily quite different, and it awkwardly bulks\nup the table of contents.  I'll probably leave it there unless it gets\nany bigger or people think splitting it out is a particularly good idea.\n\nOne issue I haven't addressed is unpushed commits.  I want to write\nsomething like \"consider setting GIT_PS1_SHOWUNPUSHED to remind people\nwhen they have committed but not yet pushed\", so I'm going to see if I\ncan add support to git-completion.bash for such an option.\n\n\t- Andrew\n"},{"id":"143073","messageId":"EBDDE922-E7D4-4668-BFA4-9770D9ABD4F2@gmail.com","threadId":"23869","inReplyTo":"4C0AC140.6090808@pileofstuff.org","subject":"Re: What's the best way to make my company migrate to Git?","fromName":"Steven Michalske","fromEmail":"smichalske@gmail.com","sentAt":"2010-06-06T08:19:08Z","receivedAt":"2010-06-06T08:19:08Z","isPatch":false,"sender":{"key":"smichalske@gmail.com","avatar":"https://gravatar.com/avatar/721f27456adc9ac84f3bb235f021a70015abb9e09222ae8622fc5579c6a203c1?d=mp&s=160"},"body":"Resent, HTML multipart got treated as spam......\n\nOn Jun 5, 2010, at 2:27 PM, Andrew Sayers wrote:\n\n> I remember now the\n> mental anguish I went through trying to explain what a local index is,\n> so I thought I'd save other people the bother :)\n\nI liked the idea that its an envelope, and you add changes to the open  \nenvelope.\n\nCommitting the changes are sealing the envelope and putting it on the  \npile of papers on your desk\n\nA push is mailing the envelope.\n\nFetch is going to the mail box getting the envelopes and throwing the  \nletters on the table, but not opening them.\n\nEveryone knows envelopes!\n"}]}