{"thread":{"id":"19925","subject":"Parallell Development / Switching to GIT","startedAt":"2009-06-25T09:52:06Z","lastAt":"2009-07-02T11:55:12Z","messageCount":13,"participants":["Patrick Neuner","Andreas Ericsson","Patrick Neuner - Futureweb.at","Jeff King","David Aguilar","Peter Harris","Johannes Sixt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"116914","messageId":"loom.20090625T095000-90@post.gmane.org","threadId":"19925","inReplyTo":null,"subject":"Parallell Development / Switching to GIT","fromName":"Patrick Neuner","fromEmail":"neuner@futureweb.at","sentAt":"2009-06-25T09:52:06Z","receivedAt":"2009-06-25T09:52:06Z","isPatch":false,"sender":{"key":"neuner@futureweb.at","avatar":null},"body":"Hello,\n\nwe are using SVN right now and with the way we do / need to develop, it seems we\nare constantly get in a merging horror. \nI did quite some reading about git now, but I am still not really sure if that\nwhat we try to accomplish can be done with git,\nOr if we are really doing something a too odd way. \n\nLet my try to describe – I also added an image. \n\n---- repo 1\n  |\n   - repo 2 (=branch of repo 1 - for our external developers)\n\nWe have the main branch and 2nd branch for external developers. \n\nWe work inside the repo1, which are usually features/updates that go life after\na short turn. \nOur external developer work on different features that will be merged into repo1\nfrom time to time. \n\nUsually during development, we sometimes need to push features from repo1 to\nrepo2, and later the features developed on repo2 will be pushed back to repo1, \nAnd also smaller bug fixes come from repo2 that needs to go into repo1. \n\nBut this is a constant process, meaning, that both branches will exist,\nespecially repo2 will exist after this feature has finished for smaller\nupdates/bugfixes. \nWe don’t want to do a new branch for each bugfix, for each new small feature,\nbut have different branches for different developer teams. \n\nSo I was wondering, if this could cause troubles with GIT in case of merging\naround without closing a branch. \n\nI am adding an link to an image that might show what I tried to explain. \nhttp://temp.in.futureweb.at/parallell-development.png\n\nThanks\nPatrick\n"},{"id":"116915","messageId":"4A434D6F.2090105@op5.se","threadId":"19925","inReplyTo":"loom.20090625T095000-90@post.gmane.org","subject":"Re: Parallell Development / Switching to GIT","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-06-25T10:11:59Z","receivedAt":"2009-06-25T10:11:59Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Patrick Neuner wrote:\n> Hello,\n> \n> we are using SVN right now and with the way we do / need to develop, it seems we\n> are constantly get in a merging horror. \n> I did quite some reading about git now, but I am still not really sure if that\n> what we try to accomplish can be done with git,\n> Or if we are really doing something a too odd way. \n> \n\nConflicts will still happen with git, but \"merge horror\" no longer applies,\nfor a couple of reasons (I come from a similar background, but switched to\ngit in late 2005).\n1. In SVN (and CVS), you're merging *unknown changes* into *unsaved state*.\n   You haven't committed your changes to the repository before you merge,\n   and you haven't (usually) looked at the upstream changes before you\n   try to merge. Git doesn't have this problem (and neither does any other\n   distributed version control system), since you first fetch changes from\n   someone else and then merge them into an already saved state. When a\n   merge conflict resolution goes wahoonie-shaped, you can easily restore\n   either of the previously saved states with zero hassle.\n2. Git has \"rerere\", which records and reuses previously resolved merge\n   conflicts, so you won't get the same merge-conflict more than once, if\n   you enable rerere.\n3. SVN (and CVS) won't remember which changes are already merged in, so\n   they will fail horribly at repeated same-branch merges. Git (and other\n   DAG-based scm's) can and do calculate the merge-base for you so you'll\n   never have to think about that yourself.\n\n> Let my try to describe – I also added an image. \n> \n> ---- repo 1\n>   |\n>    - repo 2 (=branch of repo 1 - for our external developers)\n> \n> We have the main branch and 2nd branch for external developers. \n> \n> We work inside the repo1, which are usually features/updates that go life after\n> a short turn. \n> Our external developer work on different features that will be merged into repo1\n> from time to time. \n> \n> Usually during development, we sometimes need to push features from repo1 to\n> repo2, and later the features developed on repo2 will be pushed back to repo1, \n> And also smaller bug fixes come from repo2 that needs to go into repo1. \n> \n> But this is a constant process, meaning, that both branches will exist,\n> especially repo2 will exist after this feature has finished for smaller\n> updates/bugfixes. \n> We don’t want to do a new branch for each bugfix, for each new small feature,\n> but have different branches for different developer teams. \n> \n> So I was wondering, if this could cause troubles with GIT in case of merging\n> around without closing a branch. \n> \n\nGit doesn't take away merge conflicts, but it does make it (a LOT) easier to\nhandle them when they appear, for the reasons stated above. What you want to\ndo sounds pretty reasonable, although I'd personally use feature-branches\nfor both internal and external developers, since they make it possible to\npick which features and fixes you want to release while allowing developers\nto make as many commits as they feel is necessary for each feature.\n\n> I am adding an link to an image that might show what I tried to explain. \n> http://temp.in.futureweb.at/parallell-development.png\n> \n\nWe're quite fond of ascii-art here on git@vger. Since I don't know what the\ndifferent colors mean in the picture, ascii would probably have made more\nsense (since I then could have commented on it).\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"117136","messageId":"B81058949321C8439B9D742F5F8D8FCA01A75C1D@hpserver.intranet.local","threadId":"19925","inReplyTo":"4A434D6F.2090105@op5.se","subject":"AW: Parallell Development / Switching to GIT","fromName":"Patrick Neuner - Futureweb.at","fromEmail":"neuner@futureweb.at","sentAt":"2009-06-28T17:51:26Z","receivedAt":"2009-06-28T17:51:26Z","isPatch":false,"sender":{"key":"neuner@futureweb.at","avatar":null},"body":"Hi,\n\nI have been installing and trying out GIT by now and like it. \n\nI am not sure if I understood everything correctly though. \nLet me point out 2 parts I just couldn't find a solution for so far: \n\nWe are still having the scenario of 2 branches. \nMaster\nDevelopment. \n\n1) What if I only want to merge a specific file/directly, but not the whole branch, is there a way?\n\nI found that I can git checkout development directory/ but this only works for new added files, \nit would overwrite changes within the same file of master, if it exists. So it's pretty similar to just copiing files over and commit.\n\nThe reason is, that external developers will only commit to development branch. \nThey are working on new features, and sometimes some small bugfixes, or design templates. \nThose need to be merged separately, and we try to not have more branches. As developers can access our testserver and then see what they have done and test functionality. \n\nIf we do different branches, testing on the testserver would always involve merging the branch into development branch, and especially for templates,\nthis isn't a one time update, but might be there are quite some commits, until everything fits.\n\nIs there a way?\n  \n2) We are using gitosis to give external developers access to the branches and have some kind of access restriction. \nBut we are only able to limit push rights, not pull rights. In most cases, that's not a problem, if they see master\nAnd development, but sometimes (like for external designers), we might want them to only be able to checkout some directories. \n\nImportant here is, that merging will still work (like later into the master), and that files go directly into development branch. \nSame as above, they need to test functionality, so switching branches on the testserver wouldn't work. \n\nAs I am coming from an svn background, where both things were possible, I wonder if I just didn't hit the right trail\nto get this accomplished with git?\n\nThanks\n\nPatrick\n\n\n-----Ursprüngliche Nachricht-----\nVon: Andreas Ericsson [mailto:ae@op5.se] \nGesendet: Donnerstag, 25. Juni 2009 12:12\nAn: Patrick Neuner - Futureweb.at\nCc: git@vger.kernel.org\nBetreff: Re: Parallell Development / Switching to GIT\n\nPatrick Neuner wrote:\n> Hello,\n> \n> we are using SVN right now and with the way we do / need to develop, it seems we\n> are constantly get in a merging horror. \n> I did quite some reading about git now, but I am still not really sure if that\n> what we try to accomplish can be done with git,\n> Or if we are really doing something a too odd way. \n> \n\nConflicts will still happen with git, but \"merge horror\" no longer applies,\nfor a couple of reasons (I come from a similar background, but switched to\ngit in late 2005).\n1. In SVN (and CVS), you're merging *unknown changes* into *unsaved state*.\n   You haven't committed your changes to the repository before you merge,\n   and you haven't (usually) looked at the upstream changes before you\n   try to merge. Git doesn't have this problem (and neither does any other\n   distributed version control system), since you first fetch changes from\n   someone else and then merge them into an already saved state. When a\n   merge conflict resolution goes wahoonie-shaped, you can easily restore\n   either of the previously saved states with zero hassle.\n2. Git has \"rerere\", which records and reuses previously resolved merge\n   conflicts, so you won't get the same merge-conflict more than once, if\n   you enable rerere.\n3. SVN (and CVS) won't remember which changes are already merged in, so\n   they will fail horribly at repeated same-branch merges. Git (and other\n   DAG-based scm's) can and do calculate the merge-base for you so you'll\n   never have to think about that yourself.\n\n> Let my try to describe – I also added an image. \n> \n> ---- repo 1\n>   |\n>    - repo 2 (=branch of repo 1 - for our external developers)\n> \n> We have the main branch and 2nd branch for external developers. \n> \n> We work inside the repo1, which are usually features/updates that go life after\n> a short turn. \n> Our external developer work on different features that will be merged into repo1\n> from time to time. \n> \n> Usually during development, we sometimes need to push features from repo1 to\n> repo2, and later the features developed on repo2 will be pushed back to repo1, \n> And also smaller bug fixes come from repo2 that needs to go into repo1. \n> \n> But this is a constant process, meaning, that both branches will exist,\n> especially repo2 will exist after this feature has finished for smaller\n> updates/bugfixes. \n> We don’t want to do a new branch for each bugfix, for each new small feature,\n> but have different branches for different developer teams. \n> \n> So I was wondering, if this could cause troubles with GIT in case of merging\n> around without closing a branch. \n> \n\nGit doesn't take away merge conflicts, but it does make it (a LOT) easier to\nhandle them when they appear, for the reasons stated above. What you want to\ndo sounds pretty reasonable, although I'd personally use feature-branches\nfor both internal and external developers, since they make it possible to\npick which features and fixes you want to release while allowing developers\nto make as many commits as they feel is necessary for each feature.\n\n> I am adding an link to an image that might show what I tried to explain. \n> http://temp.in.futureweb.at/parallell-development.png\n> \n\nWe're quite fond of ascii-art here on git@vger. Since I don't know what the\ndifferent colors mean in the picture, ascii would probably have made more\nsense (since I then could have commented on it).\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"117137","messageId":"20090628184714.GA8634@sigio.peff.net","threadId":"19925","inReplyTo":"B81058949321C8439B9D742F5F8D8FCA01A75C1D@hpserver.intranet.local","subject":"Re: Parallell Development / Switching to GIT","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-06-28T18:47:14Z","receivedAt":"2009-06-28T18:47:14Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jun 28, 2009 at 07:51:26PM +0200, Patrick Neuner - Futureweb.at wrote:\n\n> 1) What if I only want to merge a specific file/directly, but not the\n> whole branch, is there a way?\n> [...]\n> The reason is, that external developers will only commit to\n> development branch.  They are working on new features, and sometimes\n> some small bugfixes, or design templates.  Those need to be merged\n> separately, and we try to not have more branches. As developers can\n> access our testserver and then see what they have done and test\n> functionality.\n\nFor the situation you describe, it is not about merging a specific\n_file_, but rather you want to pick specific _commits_ from the\ndevelopment branch that have the bugfixes (or whatever) that you need,\nand merge the changes introduced by those commits (but not the rest of\nthe history).\n\nAnd that is easy to do; it is called cherry-picking, and you can use\n\"git cherry-pick\" to pick specific commits from development to master.\n\n> 2) We are using gitosis to give external developers access to the\n> branches and have some kind of access restriction.  But we are only\n> able to limit push rights, not pull rights. In most cases, that's not\n> a problem, if they see master And development, but sometimes (like for\n> external designers), we might want them to only be able to checkout\n> some directories.\n\nThere are two ways you can split access, and one will work but the other\nwill not.\n\nIn git, you generally cannot split your data by _tree_. That is, you\ncannot say \"here is all of the history for the master branch, but you\nare only allowed to look at some subset of the files.\" Because at a\nfundamental level, git is about tracking changes to the _whole_ set of\nfiles over time, and it makes the assumption that if you have commit X,\nwhich points to tree Y, which points to files A, B, and C, that you will\nhave the data for X, Y, A, B, and C in your repository.\n\nHowever, if you have your data split by _history_, that might work. That\nis, if you have a \"master\" branch and a \"development\" branch, you can in\ntheory say \"you may look at the history of master, but not of\ndevelopment\". The usual way to do that is to actually keep \"master\" and\n\"development\" in two different repositories, and only grant read\npermission in the filesystem for the \"master\" one (which obviously\nimplies doing your reading over something authenticated, like ssh).\n\nHope that helps,\n-Peff\n"},{"id":"117143","messageId":"B81058949321C8439B9D742F5F8D8FCA01A75C33@hpserver.intranet.local","threadId":"19925","inReplyTo":"20090628184714.GA8634@sigio.peff.net","subject":"AW: Parallell Development / Switching to GIT","fromName":"Patrick Neuner - Futureweb.at","fromEmail":"neuner@futureweb.at","sentAt":"2009-06-28T20:08:45Z","receivedAt":"2009-06-28T20:08:45Z","isPatch":false,"sender":{"key":"neuner@futureweb.at","avatar":null},"body":"Hi,\n\nthanks for your answers, I appreciate that.\nI read about cherry-picking, but I am not quite sure if that's really what we need. \nLets assume, you do a new feature: \n\n/featureX\n\nYou will commit it, check it out on the testserver and probably see a bug, fix it, commit and push it again. (and probably more commits after the testing person ran over other issues). \n\nWith cherry-picking, I would need to know all commits I have to pick. \nBut as there have been serveral commits, so wouldn't it be a pain to check all commits to that file or directory to have the same version?\n\nJust trying to find the right way to handle that. \n\n\nAbout the 2nd point - I am not sure if I get the different repositories thing. \nDo you talk about to different clones of the rep, and give different directory permissions on it, \nor is there a way to have like to completly different git rep's running and still merge things over (both ways)?\nI just thought this approach would break correct mergin, as it doesn't know where it's comming from. \n\nThe only thing I ran over so far is probably doing a hook for that (like a pre-pull hook if that exists). didn't get to read too much about hooks yet,\njust did the update hook that checks if the user with specific ssh key is allowed to push to a specific branch. That works pretty good and is more important in fact.\n\nBut having 2 completly different repos would be another solution, but I kinda wonder that mergin would work correctly this way (if both sides have changes). \n\nThanks\nPatrick \n\n-----Ursprüngliche Nachricht-----\nVon: Jeff King [mailto:peff@peff.net] \nGesendet: Sonntag, 28. Juni 2009 20:47\nAn: Patrick Neuner - Futureweb.at\nCc: Andreas Ericsson; git@vger.kernel.org\nBetreff: Re: Parallell Development / Switching to GIT\n\nOn Sun, Jun 28, 2009 at 07:51:26PM +0200, Patrick Neuner - Futureweb.at wrote:\n\n> 1) What if I only want to merge a specific file/directly, but not the\n> whole branch, is there a way?\n> [...]\n> The reason is, that external developers will only commit to\n> development branch.  They are working on new features, and sometimes\n> some small bugfixes, or design templates.  Those need to be merged\n> separately, and we try to not have more branches. As developers can\n> access our testserver and then see what they have done and test\n> functionality.\n\nFor the situation you describe, it is not about merging a specific\n_file_, but rather you want to pick specific _commits_ from the\ndevelopment branch that have the bugfixes (or whatever) that you need,\nand merge the changes introduced by those commits (but not the rest of\nthe history).\n\nAnd that is easy to do; it is called cherry-picking, and you can use\n\"git cherry-pick\" to pick specific commits from development to master.\n\n> 2) We are using gitosis to give external developers access to the\n> branches and have some kind of access restriction.  But we are only\n> able to limit push rights, not pull rights. In most cases, that's not\n> a problem, if they see master And development, but sometimes (like for\n> external designers), we might want them to only be able to checkout\n> some directories.\n\nThere are two ways you can split access, and one will work but the other\nwill not.\n\nIn git, you generally cannot split your data by _tree_. That is, you\ncannot say \"here is all of the history for the master branch, but you\nare only allowed to look at some subset of the files.\" Because at a\nfundamental level, git is about tracking changes to the _whole_ set of\nfiles over time, and it makes the assumption that if you have commit X,\nwhich points to tree Y, which points to files A, B, and C, that you will\nhave the data for X, Y, A, B, and C in your repository.\n\nHowever, if you have your data split by _history_, that might work. That\nis, if you have a \"master\" branch and a \"development\" branch, you can in\ntheory say \"you may look at the history of master, but not of\ndevelopment\". The usual way to do that is to actually keep \"master\" and\n\"development\" in two different repositories, and only grant read\npermission in the filesystem for the \"master\" one (which obviously\nimplies doing your reading over something authenticated, like ssh).\n\nHope that helps,\n-Peff\n"},{"id":"117145","messageId":"20090628223319.GA1951@gmail.com","threadId":"19925","inReplyTo":"B81058949321C8439B9D742F5F8D8FCA01A75C33@hpserver.intranet.local","subject":"Re: Parallell Development / Switching to GIT","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2009-06-28T22:33:20Z","receivedAt":"2009-06-28T22:33:20Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Sun, Jun 28, 2009 at 10:08:45PM +0200, Patrick Neuner - Futureweb.at wrote:\n> Hi,\n> \n> thanks for your answers, I appreciate that.\n> I read about cherry-picking, but I am not quite sure if that's really what we need. \n> Lets assume, you do a new feature: \n> \n> /featureX\n> \n> You will commit it, check it out on the testserver and probably see a bug, fix it, commit and push it again. (and probably more commits after the testing person ran over other issues). \n\n\nYou are doing parallel development with a centralized resource:\nthe test server.\n\nThat is not going to fly, and there's no amount of tooling\nthat will resolve this conflict.\n\nThe only solution is spend some time on infrastructure and\nuse virtual machines (virtualbox and other systems are known to\nwork well; I'm sure you can find better recommendations from\nothers here) to remove your central test server bottleneck.\nYou don't even need virtual machines.  It sounds like you're\ndeveloping a webapp, in which case every normal workstation\nwould do just fine for hosting a test server.\n\nOnce you have the test environment duplicated on each\ndevelopers' machine then you will find that testing and\nmanaging new features using \"feature branches\" will come\neasily and naturally.\n\nThis exercise will also improve your deployment strategy\nsubstantially.  There is no longer anything particularly\nspecial about $production_server or $test_server.  They would\nall be \"just another instance\" of the easily replicatable\nenvironment that you've created for the development team.\n\nI've intentionally described things at a high level.\nThere are plenty of good resources that go into the mechanics\nof how to use feature branches in git.\n\nOnce all of your features and bugfixes are happening on\nbranches then knowing which commits went into a particular\nfeature or bugfix becomes trivial.\n\nIn summary: use branches.\nThey are a simple yet very powerful construct.\n\n\n> With cherry-picking, I would need to know all commits I have to pick. \n> But as there have been serveral commits, so wouldn't it be a pain to check all commits to that file or directory to have the same version?\n> \n> Just trying to find the right way to handle that. \n> \n> \n> About the 2nd point - I am not sure if I get the different repositories thing. \n> Do you talk about to different clones of the rep, and give different directory permissions on it, \n> or is there a way to have like to completly different git rep's running and still merge things over (both ways)?\n> I just thought this approach would break correct mergin, as it doesn't know where it's comming from. \n> \n> The only thing I ran over so far is probably doing a hook for that (like a pre-pull hook if that exists). didn't get to read too much about hooks yet,\n> just did the update hook that checks if the user with specific ssh key is allowed to push to a specific branch. That works pretty good and is more important in fact.\n> \n> But having 2 completly different repos would be another solution, but I kinda wonder that mergin would work correctly this way (if both sides have changes). \n> \n> Thanks\n> Patrick \n> \n> -----Ursprüngliche Nachricht-----\n> Von: Jeff King [mailto:peff@peff.net] \n> Gesendet: Sonntag, 28. Juni 2009 20:47\n> An: Patrick Neuner - Futureweb.at\n> Cc: Andreas Ericsson; git@vger.kernel.org\n> Betreff: Re: Parallell Development / Switching to GIT\n> \n> On Sun, Jun 28, 2009 at 07:51:26PM +0200, Patrick Neuner - Futureweb.at wrote:\n> \n> > 1) What if I only want to merge a specific file/directly, but not the\n> > whole branch, is there a way?\n> > [...]\n> > The reason is, that external developers will only commit to\n> > development branch.  They are working on new features, and sometimes\n> > some small bugfixes, or design templates.  Those need to be merged\n> > separately, and we try to not have more branches. As developers can\n> > access our testserver and then see what they have done and test\n> > functionality.\n> \n> For the situation you describe, it is not about merging a specific\n> _file_, but rather you want to pick specific _commits_ from the\n> development branch that have the bugfixes (or whatever) that you need,\n> and merge the changes introduced by those commits (but not the rest of\n> the history).\n> \n> And that is easy to do; it is called cherry-picking, and you can use\n> \"git cherry-pick\" to pick specific commits from development to master.\n> \n> > 2) We are using gitosis to give external developers access to the\n> > branches and have some kind of access restriction.  But we are only\n> > able to limit push rights, not pull rights. In most cases, that's not\n> > a problem, if they see master And development, but sometimes (like for\n> > external designers), we might want them to only be able to checkout\n> > some directories.\n> \n> There are two ways you can split access, and one will work but the other\n> will not.\n> \n> In git, you generally cannot split your data by _tree_. That is, you\n> cannot say \"here is all of the history for the master branch, but you\n> are only allowed to look at some subset of the files.\" Because at a\n> fundamental level, git is about tracking changes to the _whole_ set of\n> files over time, and it makes the assumption that if you have commit X,\n> which points to tree Y, which points to files A, B, and C, that you will\n> have the data for X, Y, A, B, and C in your repository.\n> \n> However, if you have your data split by _history_, that might work. That\n> is, if you have a \"master\" branch and a \"development\" branch, you can in\n> theory say \"you may look at the history of master, but not of\n> development\". The usual way to do that is to actually keep \"master\" and\n> \"development\" in two different repositories, and only grant read\n> permission in the filesystem for the \"master\" one (which obviously\n> implies doing your reading over something authenticated, like ssh).\n> \n> Hope that helps,\n> -Peff\n\n-- \n\n\tDavid\n"},{"id":"117150","messageId":"4A487CCD.1040406@op5.se","threadId":"19925","inReplyTo":"B81058949321C8439B9D742F5F8D8FCA01A75C33@hpserver.intranet.local","subject":"Re: AW: Parallell Development / Switching to GIT","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2009-06-29T08:35:25Z","receivedAt":"2009-06-29T08:35:25Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Patrick Neuner - Futureweb.at wrote:\n> Hi,\n> \n> thanks for your answers, I appreciate that. I read about\n> cherry-picking, but I am not quite sure if that's really what we\n> need. Lets assume, you do a new feature:\n> \n> /featureX\n> \n> You will commit it, check it out on the testserver and probably see a\n> bug, fix it, commit and push it again. (and probably more commits\n> after the testing person ran over other issues).\n> \n> With cherry-picking, I would need to know all commits I have to pick.\n>  But as there have been serveral commits, so wouldn't it be a pain to\n> check all commits to that file or directory to have the same version?\n> \n> \n> Just trying to find the right way to handle that.\n> \n\nI can't help but think you're going about this the entirely wrong way.\nIt sounds as if every developer has to be able to log in to the test\nserver to try out their stuff, which sounds just plain insane to me\n(unless you're developing supercomputer applications, but a company\nnamed \"futureweb\" probably doesn't do that).\n\nAnyways, the way you *merge* specific features in git is to develop\nthem on a topic-branch. If you absolutely do not want that (though I\ncan't think why, since branching is both cheap and easy in git), you\nhave to resort to cherry-picking. You cannot merge and say \"I want\nonly changes to these and those files\" because you'd end up with \neither a disconnected DAG (meaning git wouldn't know where to merge\nfrom when you want to merge next), or with a connected DAG that\n*still* doesn't have all the changes.\n\nIn short; Your workflow seems built around the capabilities and\nshortcomings of SVN. Git has a different set of capabilities and\nshortcomings, so it's natural that some things will feel awkward.\nIt's like bringing a skateboard to a formula 1 race, really.\n\nWith SVN, noone uses feature branches, because merging is a serious\npain. With SVN, every active contributor has commit access to the\ncentral repository, because without it they'd have to juggle patches,\nwhich is boring, and that would hinder them in their work.\n\nWith git, a lot of people use feature-branches, because merging is\nreally easy. With git, there's no real need to let every developer\nhave write access to the \"officially blessed\" repository. Instead\nit's often useful to have each developer set up his/her own public\nrepository and then issue \"please pull\" requests, allowing the\nmaintainer(s) to fetch their changes, inspect them and then decide\nwhich of the changes to make public. A lot of active git contributors\nhave their own repositories, and nearly all of the linux subsystem\nmaintainers have them too. Git also makes it really easy to send\npatches by email (and apply such emailed patches). Since git is a\ndistributed version control system, each developer still gains the\nfull benefit of using an SCM, while the trusted people act as gate-\nkeepers for patches that get sent in. But I digress...\n\n> \n> About the 2nd point - I am not sure if I get the different\n> repositories thing. Do you talk about to different clones of the rep,\n> and give different directory permissions on it,\n\nI'm sure he is, yes.\n\n> or is there a way to\n> have like to completly different git rep's running and still merge\n> things over (both ways)?\n\nYes, there is. That's what happens as soon as you have a public repo\nand a local repo, and it's how all distributed version control systems\nwork. They're both separate repositories, but you can merge til your\nheart's content between them, ofcourse.\n\n> I just thought this approach would break\n> correct mergin, as it doesn't know where it's comming from.\n> \n\nbzzt! wrong. You're thinking SVN. Git has a DAG, with each revision\nhaving a unique name, based on its content and all its history, so\nseparate copies of the same repository can be merged without problem\nat all. This is how Linux development happens; The subsystem maintainers\nall have their own repositories, and Linus merges from them during each\nmerge-window. I think there are about 30 \"official\" Linux repositories\nif you count all the subsystem ones. Git was *designed* for scenarios\nlike that, so it does it very, very well.\n\n> The only thing I ran over so far is probably doing a hook for that\n> (like a pre-pull hook if that exists). didn't get to read too much\n> about hooks yet, just did the update hook that checks if the user\n> with specific ssh key is allowed to push to a specific branch. That\n> works pretty good and is more important in fact.\n> \n> But having 2 completly different repos would be another solution, but\n> I kinda wonder that mergin would work correctly this way (if both\n> sides have changes).\n> \n\ngit help merge-base\n\nIn SVN, you need to know exactly which revision you've merged before\nin order to once again merge the same branch. Git holds that knowledge\nalready. Spend some time with gitk after following the git tutorial\nand you'll probably get a much better grasp of how the DAG works and\nhow git uses it.\n\nI'd advise you to clone the linux kernel and inspecting its history\nusing gitk. Every merge-commit you see which has a line saying something\nlike \"merge foo bar frotz of git://example.com/path/to/repo.git\" is a\nmerge with branches from different repositories. I wouldn't be the least\nsurprised if you find more than 5000 such merges in the linux kernel\nhistory.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"117169","messageId":"eaa105840906290937h14868eb8v7928951876f7e8f1@mail.gmail.com","threadId":"19925","inReplyTo":"4A487CCD.1040406@op5.se","subject":"Re: AW: Parallell Development / Switching to GIT","fromName":"Peter Harris","fromEmail":"git@peter.is-a-geek.org","sentAt":"2009-06-29T16:37:42Z","receivedAt":"2009-06-29T16:37:42Z","isPatch":false,"sender":{"key":"git@peter.is-a-geek.org","avatar":null},"body":"On Mon, Jun 29, 2009 at 4:35 AM, Andreas Ericsson wrote:\n> Patrick Neuner - Futureweb.at wrote:\n>> But having 2 completly different repos would be another solution, but\n>> I kinda wonder that mergin would work correctly this way (if both\n>> sides have changes).\n\n> I'd advise you to clone the linux kernel and inspecting its history\n> using gitk. Every merge-commit you see which has a line saying something\n> like \"merge foo bar frotz of git://example.com/path/to/repo.git\" is a\n> merge with branches from different repositories. I wouldn't be the least\n> surprised if you find more than 5000 such merges in the linux kernel\n> history.\n\nYou got me curious, so I looked:\n\n~/linux-2.6$ git log | grep -c \"Merge.*git:\"\n4431\n\nNot quite 5000, but still an average of roughly 2.88 such merges per\nday, every single day, since the kernel was moved to git in 2005.\n\nPeter Harris\n"},{"id":"117207","messageId":"20090630053252.GA29643@sigio.peff.net","threadId":"19925","inReplyTo":"B81058949321C8439B9D742F5F8D8FCA01A75C33@hpserver.intranet.local","subject":"Re: Parallell Development / Switching to GIT","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-06-30T05:32:54Z","receivedAt":"2009-06-30T05:32:54Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Jun 28, 2009 at 10:08:45PM +0200, Patrick Neuner - Futureweb.at wrote:\n\n> I read about cherry-picking, but I am not quite sure if that's really\n> what we need.  Lets assume, you do a new feature:\n>\n> /featureX\n>\n> You will commit it, check it out on the testserver and probably see a\n> bug, fix it, commit and push it again. (and probably more commits\n> after the testing person ran over other issues).\n>\n> With cherry-picking, I would need to know all commits I have to pick.\n> But as there have been serveral commits, so wouldn't it be a pain to\n> check all commits to that file or directory to have the same version?\n>\n> Just trying to find the right way to handle that.\n\nI don't quite understand what you are asking. You make some commits\npushing a new feature forward. While testing, you see some bugs. You fix\nthe bugs and make new commits. Now you realize you want those bugfixes\non some other branch. So you cherry-pick them away. Yes, you have to\nfigure out which commits you want. You can use \"git log\" or \"git log\n<set of files>\" to look through the list of commits and pick them out.\n\nWhen you say \"wouldn't it be a pain to check all commits to that file or\ndirectory to have the same version?\" I can't quite parse what you are\ntrying to say. Can you rephrase it?\n\n> Do you talk about to different clones of the rep, and give different directory permissions on it, \n> or is there a way to have like to completly different git rep's running and still merge things over (both ways)?\n> I just thought this approach would break correct mergin, as it doesn't know where it's comming from. \n\nNo, it doesn't break merging at all. You will have two different\nrepositories, but they may actually contain quite a similar subset of\ncommits.  That subset will be the shared part of the history graph, and\nthen each one will have commits on top. Periodically features from\ndevelopment will get merged to master, which will make those merged bits\npart of the shared history.\n\nTo git, two branches in the same repo is exactly the same as two repos,\neach with its own branch.\n\n> The only thing I ran over so far is probably doing a hook for that\n> (like a pre-pull hook if that exists). didn't get to read too much\n> about hooks yet, just did the update hook that checks if the user with\n> specific ssh key is allowed to push to a specific branch. That works\n> pretty good and is more important in fact.\n\nYes, that is the hook you would need, but it doesn't exist yet.\n\n> But having 2 completly different repos would be another solution, but\n> I kinda wonder that mergin would work correctly this way (if both\n> sides have changes). \n\nOf course it is still possible to have merge conflicts, but it is no\ndifferent than merging two branches from the same repository.\n\n-Peff\n"},{"id":"117333","messageId":"B81058949321C8439B9D742F5F8D8FCA01A75CFA@hpserver.intranet.local","threadId":"19925","inReplyTo":"4A487CCD.1040406@op5.se","subject":"AW: AW: Parallell Development / Switching to GIT","fromName":"Patrick Neuner - Futureweb.at","fromEmail":"neuner@futureweb.at","sentAt":"2009-07-02T00:47:34Z","receivedAt":"2009-07-02T00:47:34Z","isPatch":false,"sender":{"key":"neuner@futureweb.at","avatar":null},"body":"Hello,\n\nthanks for your really helpful and detailled information I got, it helped us a lot to get started. \nAnd I got the point of using branches and thinking different about the workflow. \n\nI stumbled over something I just can't figure out, I kinda feel stupid as it must be something really simple, but going up and down docs, just can't figure it out. \n\nWe use the update-hook to check into which branches pushes are allowed per different ssh keys. \nNow, I wonder how I am able to create branches that are below another branch. \n\nLike \nRefs/heads/master\nRefs/heads/dev\nRefs/heads/dev/featureA\nRefs/heads/dev/featureB\n\nInstead of\nRefs/heads/featureA\n\nAnything I tried either results in an error or creates the branch under /refs/heads/. \n\nFor the update hook this would be helpful as we won't always be able to pull from a developer, so they would need to push their feature branches up to our public one. (as we prefer it this way instead of receiving patches). \n\nI found on following page what we need, so I bet there is a way I just couldn't figure out how?\nBasically the refs/heads/bw/.* example is what I am seeking, so each developer can push feature branches up under development. \nI do understand it's nothing different if the branch is under /refs/heads, but first it would be cleaner, 2nd access control is better handled. \n\n++\nhttp://www.kernel.org/pub/software/scm/git/docs/howto/update-hook-example.txt\n\n        refs/heads/master\tjunio\n\t+refs/heads/pu\t\tjunio\n        refs/heads/cogito$\tpasky\n        refs/heads/bw/.*\tlinus\n        refs/heads/tmp/.*\t.*\n        refs/tags/v[0-9].*\tjunio\n\nWith this, *Linus can push or create \"bw/penguin\" or \"bw/zebra\"\nor \"bw/panda\" branches*, Pasky can do only \"cogito\", and JC can\ndo master and pu branches and make versioned tags.  And anybody\ncan do tmp/blah branches. The '+' sign at the pu record means\nthat JC can make non-fast-forward pushes on it.\n++\n\nThanks\n\n\nPatrick \n\n\n-----Ursprüngliche Nachricht-----\nVon: Andreas Ericsson [mailto:ae@op5.se] \nGesendet: Montag, 29. Juni 2009 10:35\nAn: Patrick Neuner - Futureweb.at\nCc: Jeff King; git@vger.kernel.org\nBetreff: Re: AW: Parallell Development / Switching to GIT\n\nPatrick Neuner - Futureweb.at wrote:\n> Hi,\n> \n> thanks for your answers, I appreciate that. I read about\n> cherry-picking, but I am not quite sure if that's really what we\n> need. Lets assume, you do a new feature:\n> \n> /featureX\n> \n> You will commit it, check it out on the testserver and probably see a\n> bug, fix it, commit and push it again. (and probably more commits\n> after the testing person ran over other issues).\n> \n> With cherry-picking, I would need to know all commits I have to pick.\n>  But as there have been serveral commits, so wouldn't it be a pain to\n> check all commits to that file or directory to have the same version?\n> \n> \n> Just trying to find the right way to handle that.\n> \n\nI can't help but think you're going about this the entirely wrong way.\nIt sounds as if every developer has to be able to log in to the test\nserver to try out their stuff, which sounds just plain insane to me\n(unless you're developing supercomputer applications, but a company\nnamed \"futureweb\" probably doesn't do that).\n\nAnyways, the way you *merge* specific features in git is to develop\nthem on a topic-branch. If you absolutely do not want that (though I\ncan't think why, since branching is both cheap and easy in git), you\nhave to resort to cherry-picking. You cannot merge and say \"I want\nonly changes to these and those files\" because you'd end up with \neither a disconnected DAG (meaning git wouldn't know where to merge\nfrom when you want to merge next), or with a connected DAG that\n*still* doesn't have all the changes.\n\nIn short; Your workflow seems built around the capabilities and\nshortcomings of SVN. Git has a different set of capabilities and\nshortcomings, so it's natural that some things will feel awkward.\nIt's like bringing a skateboard to a formula 1 race, really.\n\nWith SVN, noone uses feature branches, because merging is a serious\npain. With SVN, every active contributor has commit access to the\ncentral repository, because without it they'd have to juggle patches,\nwhich is boring, and that would hinder them in their work.\n\nWith git, a lot of people use feature-branches, because merging is\nreally easy. With git, there's no real need to let every developer\nhave write access to the \"officially blessed\" repository. Instead\nit's often useful to have each developer set up his/her own public\nrepository and then issue \"please pull\" requests, allowing the\nmaintainer(s) to fetch their changes, inspect them and then decide\nwhich of the changes to make public. A lot of active git contributors\nhave their own repositories, and nearly all of the linux subsystem\nmaintainers have them too. Git also makes it really easy to send\npatches by email (and apply such emailed patches). Since git is a\ndistributed version control system, each developer still gains the\nfull benefit of using an SCM, while the trusted people act as gate-\nkeepers for patches that get sent in. But I digress...\n\n> \n> About the 2nd point - I am not sure if I get the different\n> repositories thing. Do you talk about to different clones of the rep,\n> and give different directory permissions on it,\n\nI'm sure he is, yes.\n\n> or is there a way to\n> have like to completly different git rep's running and still merge\n> things over (both ways)?\n\nYes, there is. That's what happens as soon as you have a public repo\nand a local repo, and it's how all distributed version control systems\nwork. They're both separate repositories, but you can merge til your\nheart's content between them, ofcourse.\n\n> I just thought this approach would break\n> correct mergin, as it doesn't know where it's comming from.\n> \n\nbzzt! wrong. You're thinking SVN. Git has a DAG, with each revision\nhaving a unique name, based on its content and all its history, so\nseparate copies of the same repository can be merged without problem\nat all. This is how Linux development happens; The subsystem maintainers\nall have their own repositories, and Linus merges from them during each\nmerge-window. I think there are about 30 \"official\" Linux repositories\nif you count all the subsystem ones. Git was *designed* for scenarios\nlike that, so it does it very, very well.\n\n> The only thing I ran over so far is probably doing a hook for that\n> (like a pre-pull hook if that exists). didn't get to read too much\n> about hooks yet, just did the update hook that checks if the user\n> with specific ssh key is allowed to push to a specific branch. That\n> works pretty good and is more important in fact.\n> \n> But having 2 completly different repos would be another solution, but\n> I kinda wonder that mergin would work correctly this way (if both\n> sides have changes).\n> \n\ngit help merge-base\n\nIn SVN, you need to know exactly which revision you've merged before\nin order to once again merge the same branch. Git holds that knowledge\nalready. Spend some time with gitk after following the git tutorial\nand you'll probably get a much better grasp of how the DAG works and\nhow git uses it.\n\nI'd advise you to clone the linux kernel and inspecting its history\nusing gitk. Every merge-commit you see which has a line saying something\nlike \"merge foo bar frotz of git://example.com/path/to/repo.git\" is a\nmerge with branches from different repositories. I wouldn't be the least\nsurprised if you find more than 5000 such merges in the linux kernel\nhistory.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"117343","messageId":"4A4C51B7.7010000@viscovery.net","threadId":"19925","inReplyTo":"B81058949321C8439B9D742F5F8D8FCA01A75CFA@hpserver.intranet.local","subject":"Re: AW: AW: Parallell Development / Switching to GIT","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-07-02T06:20:39Z","receivedAt":"2009-07-02T06:20:39Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Patrick Neuner - Futureweb.at schrieb:\n> We use the update-hook to check into which branches pushes are allowed per different ssh keys. \n> Now, I wonder how I am able to create branches that are below another branch. \n> \n> Like \n> Refs/heads/master\n> Refs/heads/dev\n> Refs/heads/dev/featureA\n> Refs/heads/dev/featureB\n> \n> Instead of\n> Refs/heads/featureA\n> \n> Anything I tried either results in an error or creates the branch under /refs/heads/. \n\nYou cannot have refs/heads/dev and refs/heads/dev/featureA at the same\ntime, just like you cannot have a file and a directory with the same name\nat the same time. In fact, the refs \"database\" is implemented as physical\nfiles on the file system.\n\n-- Hannes\n"},{"id":"117355","messageId":"B81058949321C8439B9D742F5F8D8FCA01A75D15@hpserver.intranet.local","threadId":"19925","inReplyTo":"4A4C51B7.7010000@viscovery.net","subject":"AW: AW: AW: Parallell Development / Switching to GIT","fromName":"Patrick Neuner - Futureweb.at","fromEmail":"neuner@futureweb.at","sentAt":"2009-07-02T11:44:10Z","receivedAt":"2009-07-02T11:44:10Z","isPatch":false,"sender":{"key":"neuner@futureweb.at","avatar":null},"body":"Hi,\n\nok, I see, well then this howto (at the end of page) seems to be misleading. \nhttp://www.kernel.org/pub/software/scm/git/docs/howto/update-hook-example.txt\nas it actually works with the update hook, but not with git itself. \n\nWell, anyway, no problem, we will do it different. \n\nThanks\n\nPatrick Neuner\nFutureweb.at\nInnsbrucker Str. 4\n6380 St. Johann\n\nneuner@futureweb.at\nwww.futureweb.at\n\nFon: +43 (0) 5352 65335\nFax: +43 (0) 5352 63148\nGratis über Skype anrufen | Skype-ID: futureweb\n\n\n> -----Ursprüngliche Nachricht-----\n> Von: Johannes Sixt [mailto:j.sixt@viscovery.net]\n> Gesendet: Donnerstag, 02. Juli 2009 08:21\n> An: Patrick Neuner - Futureweb.at\n> Cc: Andreas Ericsson; Jeff King; git@vger.kernel.org; David Aguilar\n> Betreff: Re: AW: AW: Parallell Development / Switching to GIT\n> \n> Patrick Neuner - Futureweb.at schrieb:\n> > We use the update-hook to check into which branches pushes are\n> allowed per different ssh keys.\n> > Now, I wonder how I am able to create branches that are below another\n> branch.\n> >\n> > Like\n> > Refs/heads/master\n> > Refs/heads/dev\n> > Refs/heads/dev/featureA\n> > Refs/heads/dev/featureB\n> >\n> > Instead of\n> > Refs/heads/featureA\n> >\n> > Anything I tried either results in an error or creates the branch\n> under /refs/heads/.\n> \n> You cannot have refs/heads/dev and refs/heads/dev/featureA at the same\n> time, just like you cannot have a file and a directory with the same\n> name\n> at the same time. In fact, the refs \"database\" is implemented as\n> physical\n> files on the file system.\n> \n> -- Hannes\n"},{"id":"117356","messageId":"4A4CA020.5020108@viscovery.net","threadId":"19925","inReplyTo":"B81058949321C8439B9D742F5F8D8FCA01A75D15@hpserver.intranet.local","subject":"Re: Parallell Development / Switching to GIT","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-07-02T11:55:12Z","receivedAt":"2009-07-02T11:55:12Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Please don't top-post on this list.\n\nPatrick Neuner - Futureweb.at schrieb:\n>> You cannot have refs/heads/dev and refs/heads/dev/featureA at the same\n>> time, just like you cannot have a file and a directory with the same\n>> name\n>> at the same time. In fact, the refs \"database\" is implemented as\n>> physical\n>> files on the file system.\n> \n> ok, I see, well then this howto (at the end of page) seems to be misleading. \n> http://www.kernel.org/pub/software/scm/git/docs/howto/update-hook-example.txt\n> as it actually works with the update hook, but not with git itself. \n\nAre you refering to the example line such as\n\n        refs/heads/bw/.*\tlinus\n\n\n? Of course, you can have refs/heads/dev/featureA in your repository (and\nthe shortened branch name would obviously be \"dev/featureA\"), but then you\ncannot have a branch named \"dev\", i.e. refs/heads/dev.\n\nI don't see how the cited document would be misleading in this regard.\n\n-- Hannes\n"}]}