{"thread":{"id":"21490","subject":"Git & Project Workflow","startedAt":"2009-11-06T00:19:31Z","lastAt":"2009-11-06T21:44:53Z","messageCount":2,"participants":["Tommy Wang","Nicolas Sebrecht"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"126936","messageId":"ae09c2a40911051619s36c9a781pdb403fb9140affdf@mail.gmail.com","threadId":"21490","inReplyTo":null,"subject":"Git & Project Workflow","fromName":"Tommy Wang","fromEmail":"subscription@august8.net","sentAt":"2009-11-06T00:19:31Z","receivedAt":"2009-11-06T00:19:31Z","isPatch":false,"sender":{"key":"subscription@august8.net","avatar":null},"body":"Hi,\n\nI'm trying to set up a project using git, and I'm having a hard time\nfiguring out the best way to implement one of my workflows.\n\nLets say I have a repository \"main\".  Some of my developers will have\nfull access to this repository, while others should have access only\nto certain parts of it (and, no, unfortunately the files are scattered\nall over the place, and reorganizing isn't an option, so I can't use\nsubtrees).\n\nI've attempted to solve this project by cloning the project into\nanother repository \"limited\".  Now, half of my developers can work off\nfrom \"main\", while the other half can work from \"limited\".\nIncidentally, its okay that the original source is visible in limited,\nI just don't want the work we put into \"main\" to show up in \"limited\".\n\nSo, lets say my \"main\" developer makes some changes to the project.\nSome of his changes are to kept in \"main\" only, while other changes\nneed to be pushed into \"limited\".  I can maybe force developers to\nkeep changes in common files in separate commits, and just cherry pick\nthem into \"limited\".  \"Limited\" developers can then pull those changes\ninto his local repository, resolve conflicts, (rebase), and push them\nback into \"limited\".  At some point later in time, lets suppose we\nneed to push changes made in limited back to main.  So, our main\ndevelopers will cherry pick again the newest changes into limited (to\nkeep the conflicts down).  Limited developers will then\ncommit/resolve/rebase their work into limited, and let the main\ndevelopers know that they're ready.  The main developers will now pull\nfrom limited -- and since we (likely) haven't changed main, the pull\nshould be pretty conflict free (git does keep track of cherry-commits\nin merges, right?).\n\nMy question is, is cherry-picking really the best way to do this?\nWhat I'd really like to do is to create the limited repository by\ndoing a filter-branch and removing secure files out of the repository\nentirely.  After doing this, though, it makes it difficult/impossible\nto move changes between the two repositories.  I tried a number of\napproaches, including trying to graft the two repositories together\nafter the filter-branch to make push/pull work as simple\nmerges/fast-forwards.  I would have to figure out way to filter\ncommits to make sure that main doesn't push a secure file into\nlimited, and that limited doesn't try to do something silly like\ncreating a secure file.  Perhaps I could use filter-branch to rewrite\nthese commits as well.  But, being that filter-branch totally changes\nthe commit ids, I figure that this approach really doesn't have any\nmerit.\n\nI also considered doing something like this:\n\n# create main & limited from upstream source\ngit clone upstream main\ngit clone main limited\n\n# remove secure files from limited\ncd limited\ngit rm -r secure files\ngit commit\n\n# fake a merge to keep histories correct\ncd main\ngit pull -s ours limited\n\n# pulling from limited worked well, and would only get changes made after the rm\ncd main\ngit pull limited master\n\n# pull from main didn't work so well --> but I probably should be\ncherry-picking here anyway?\ncd limited\ngit pull main master\n\nI'm not sure why I'm trying so hard to avoid cherry-picking.  Probably\ndue to the fact that developers need to be more intimate with git, and\nthat it takes considerably more time to look through a list of\ncommits, and pick out the ones that can be moved from main -> limited.\n\nIs there a way to generate a list of commits based on a list of files\n(paths aren't good enough, since my files are scattered all over the\nplace) that can be found in main but not limited?  Perhaps I can write\na script that can be used to automate the cherry-picking from main ->\nlimited.  If we run this script right after we resolve all the\nconflicts from a limited -> main merge, we should be able to avoid all\nconflicts.\n\nAnyway, I'm hoping for some thoughts/direction on how I may be able to\nsolve my problem.  Perhaps there is a magical solution that is plainly\nobvious to someone with more git experience?\n\nThanks,\nTommy\n"},{"id":"127004","messageId":"20091106214452.GA13724@vidovic","threadId":"21490","inReplyTo":"ae09c2a40911051619s36c9a781pdb403fb9140affdf@mail.gmail.com","subject":"Re: Git & Project Workflow","fromName":"Nicolas Sebrecht","fromEmail":"nicolas.s.dev@gmx.fr","sentAt":"2009-11-06T21:44:53Z","receivedAt":"2009-11-06T21:44:53Z","isPatch":false,"sender":{"key":"nicolas.s.dev@gmx.fr","avatar":null},"body":"The 05/11/09, Tommy Wang wrote:\n\n> Hi,\n\nHi,\n\n>      it takes considerably more time to look through a list of\n> commits, and pick out the ones that can be moved from main -> limited.\n\nInstead of doing this massive (time consuming) cherry-picking, why don't\nyou avoid the whole \"main -> limited\" workflow ? This looks a bit ugly\nfor me.\n\nI think that the main developers should work by default with the limited\nrepo and only commit for the secret files into main. This would result\nin only pulling limited work into main (\"limited -> main\" workflow).\n\nLet's rename main to secret and limited to normal to have the semantic\nstick with my point. In this case, whole developers work with normal for\nthe \"normal\" tasks. If they need a secret change, secret developers\ncommit and push to secret. Then, you only need to pull normal from\nsecret and resolve conflicts in one place.\n\n\n-- \nNicolas Sebrecht\n"}]}