{"thread":{"id":"25997","subject":"Push to all repositories","startedAt":"2010-12-08T17:39:43Z","lastAt":"2011-01-02T09:54:25Z","messageCount":9,"participants":["Kevin Sheedy","Jonathan Nieder","Nguyen Thai Ngoc Duy","Martin von Zweigbergk","Enrico Weigelt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"157613","messageId":"1291829983410-5816069.post@n2.nabble.com","threadId":"25997","inReplyTo":null,"subject":"Push to all repositories","fromName":"Kevin Sheedy","fromEmail":"kevinsheedy@gmail.com","sentAt":"2010-12-08T17:39:43Z","receivedAt":"2010-12-08T17:39:43Z","isPatch":false,"sender":{"key":"kevinsheedy@gmail.com","avatar":"https://gravatar.com/avatar/f3999130e74059a970f3bdc86f7521aab79a66ba4b00aa469952b103466bacbb?d=mp&s=160"},"body":"\nWill git let me push my changes to every member of the team?\n\nI find a big problem with CVS & SVN is that I have to explicitly update my\ncode in order to keep in sync. This is a real pain-point as I often have to\ndo it several times a day and it can be very slow. We still regularly get\nproblems caused by developers being out of sync. Most people become\nreluctant to do an update at all as they fear it will cause errors.\n\nClearcase has a great solution to this, \"dynamic views\". Whenever I check in\nsome code, the whole team magically get's my changes straight away.\nNormally, they don't even notice, they're just forced to stay in sync. This\ndrastically reduces the number of 'code conflicts' where people make changes\nto 'stale' files. This enforces the practise of \"catching errors early\". It\nalso keeps developers \"honest\" as they have to keep the quality of their\ncheckins high lest they get shouted at by the rest of the team.\n\nWill git let a team stay in sync without everyone having to do manual\nupdates?\nBasically, I want every developer to be able to push their code to the whole\nteam.\n-- \nView this message in context: http://git.661346.n2.nabble.com/Push-to-all-repositories-tp5816069p5816069.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"157615","messageId":"20101208180049.GC5687@burratino","threadId":"25997","inReplyTo":"1291829983410-5816069.post@n2.nabble.com","subject":"Re: Push to all repositories","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-12-08T18:00:49Z","receivedAt":"2010-12-08T18:00:49Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Kevin Sheedy wrote:\n\n> Basically, I want every developer to be able to push their code to the whole\n> team.\n\nWhat does this mean, in practice? Do you want (1) the code in their\nworking directories to change under their feet, (2) the code you've\nwritten to be immediately available to them in case they pull out the\nnetwork cable, or something else?\n\nIf case (2), then git currently provides support for fetching from\nmultiple repositories at once:\n\n\t$ git fetch --multiple alice bob sam\n\nbut does not include such support for pushing. One can do so explicitly\nlike so:\n\n\t$ for repo in alice blob sam\n\t do\n\t\tgit push $repo *:refs/remotes/kevin/*\n\t done\n\nRegards,\nJonathan\n"},{"id":"157645","messageId":"1291849156593-5817177.post@n2.nabble.com","threadId":"25997","inReplyTo":"20101208180049.GC5687@burratino","subject":"Re: Push to all repositories","fromName":"Kevin Sheedy","fromEmail":"kevinsheedy@gmail.com","sentAt":"2010-12-08T22:59:16Z","receivedAt":"2010-12-08T22:59:16Z","isPatch":false,"sender":{"key":"kevinsheedy@gmail.com","avatar":"https://gravatar.com/avatar/f3999130e74059a970f3bdc86f7521aab79a66ba4b00aa469952b103466bacbb?d=mp&s=160"},"body":"\nI would like (1), have the code changed under my feet.\nObviously, this would exclude my locally modified files. Also, a user could\nlock local files or turn off automatic updates altogether.\n\nClearcase dynamic views are a lovely way to collaborate with a team (despite\ntheir many technical problems). They remove the need to perform manual\nupdates. Teams just stay in sync by default. There are fewer code\ncollisions. Problems get spotted and fixed sooner. It you don't want\nsomething changed under your feet, that's supported too.\n\nI guess the question is: \"By default, do you want the latest code or not?\"\n(This is similar to how the Google Chrome Browser defaults to giving you\nupdates. When you're not looking, it just updates itself in the background.\nYou just trust that it will use this power wisely, and it does.)\n\nIt could work something like this:\nEvery time a repository is cloned, the location of the new clone would be\nadded to the repository. When a user does a push, it gets pushed out to\neveryone repository on this list. Each user could retain total control over\nthese updates.\n\nDo you see any reason why this couldn't be added as an enhancement to git?\n\nCheers\nKev\n-- \nView this message in context: http://git.661346.n2.nabble.com/Push-to-all-repositories-tp5816069p5817177.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"157684","messageId":"1291898174244-5818757.post@n2.nabble.com","threadId":"25997","inReplyTo":"1291849156593-5817177.post@n2.nabble.com","subject":"Re: Push to all repositories","fromName":"Kevin Sheedy","fromEmail":"kevinsheedy@gmail.com","sentAt":"2010-12-09T12:36:14Z","receivedAt":"2010-12-09T12:36:14Z","isPatch":false,"sender":{"key":"kevinsheedy@gmail.com","avatar":"https://gravatar.com/avatar/f3999130e74059a970f3bdc86f7521aab79a66ba4b00aa469952b103466bacbb?d=mp&s=160"},"body":"\nIn summary, I think it would be cool if there was a programmatic way of\nsaying:\n\"Hey everybody, I've changed some code on branch x and I think you should\nhave it\"\n\nEveryone else would then have the choices:\n1) Always accept, I trust you (but don't blow away my current work,\nobviously)\n2) Always ignore, I'll get it when I'm good and ready\n\nKev\n-- \nView this message in context: http://git.661346.n2.nabble.com/Push-to-all-repositories-tp5816069p5818757.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"157685","messageId":"AANLkTim_4sqyrE=MFOVxskANNL9-z29=iH3grNae7Yt3@mail.gmail.com","threadId":"25997","inReplyTo":"1291898174244-5818757.post@n2.nabble.com","subject":"Re: Push to all repositories","fromName":"Nguyen Thai Ngoc Duy","fromEmail":"pclouds@gmail.com","sentAt":"2010-12-09T12:47:36Z","receivedAt":"2010-12-09T12:47:36Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Dec 9, 2010 at 7:36 PM, Kevin Sheedy wrote:\n>\n> In summary, I think it would be cool if there was a programmatic way of\n> saying:\n> \"Hey everybody, I've changed some code on branch x and I think you should\n> have it\"\n\nSee \"update\" hook in githooks man page. Add \"pushall\" alias for \"for\nrepo in...\" from Jonathan's mail.\n-- \nDuy\n"},{"id":"157688","messageId":"AANLkTik9CxVD9A-2QEyD_tZiyYoCOitfViWucGCudzh-@mail.gmail.com","threadId":"25997","inReplyTo":"1291898174244-5818757.post@n2.nabble.com","subject":"Re: Push to all repositories","fromName":"Martin von Zweigbergk","fromEmail":"martin.von.zweigbergk@gmail.com","sentAt":"2010-12-09T13:36:44Z","receivedAt":"2010-12-09T13:36:44Z","isPatch":false,"sender":{"key":"martinvonz@gmail.com","avatar":"https://avatars.githubusercontent.com/u/891642?v=4"},"body":"On Thu, Dec 9, 2010 at 7:36 AM, Kevin Sheedy wrote:\n>\n> In summary, I think it would be cool if there was a programmatic way of\n> saying:\n> \"Hey everybody, I've changed some code on branch x and I think you should\n> have it\"\n>\n> Everyone else would then have the choices:\n> 1) Always accept, I trust you (but don't blow away my current work,\n> obviously)\n\nI think the closest thing would be a cron job that runs \"git pull\"\nevery minute or so. A difference from dynamic views is that it would\nno longer update your work tree once your changes start conflicting\nwith the upstream changes (in dynamic views, all unmodified files\nwould be updated).\n\nHowever, rather than trying to make Git behave just like ClearCase\ndynamic views (there are many other things to consider than automatic\nupdates), I think you would be better off if you actually use\nClearCase dynamic views instead.\n\n> 2) Always ignore, I'll get it when I'm good and ready\n\nThis is of course the easy case; just run \"git pull\" manually.\n\n\n\n/Martin\n"},{"id":"157713","messageId":"20101209195204.GB6884@burratino","threadId":"25997","inReplyTo":"AANLkTik9CxVD9A-2QEyD_tZiyYoCOitfViWucGCudzh-@mail.gmail.com","subject":"Re: Push to all repositories","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-12-09T19:52:04Z","receivedAt":"2010-12-09T19:52:04Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Martin von Zweigbergk wrote:\n\n> However, rather than trying to make Git behave just like ClearCase\n> dynamic views (there are many other things to consider than automatic\n> updates), I think you would be better off if you actually use\n> ClearCase dynamic views instead.\n\nYes. Or a network filesystem + unionfs. Or a wiki.\n\nThe part I did not mention is why git does not work this way out of\nthe box. It has something to do with the nature of projects it has\nbeen used on traditionally (computer programs that occasionally undergo\nglobal changes in API).\n\nConsider a project in a patches+tarballs workflow. It begins like\nthis:\n\n 1. Acquire a tarball with the version you want to base your work on.\n 2. Untar.\n 3. Copy the result to save the current state.\n 4. Test it.\n 5. Fix a bug or add a feature.\n 6. Make a patch with \"diff -pruN\"\n 7. Return to step 3.\n ...\n 8. Looks good; email out the patches to get some feedback.\n\nNow another person wants to test the patches; so she tries:\n\n 1. Acquire a tarball with the version you want to test against.\n 2. Untar.\n 3. Apply patches with \"patch -p1\".\n\nWait a second --- the patches don't apply! Or worse, they\napply but the result is broken. Okay:\n\n 4. Complain to the patch author.\n\nFinally the patch author has more work to do:\n\n 9. Acquire a newer tarball, and use either \"patch --reject-file\"\n or rcs \"merge\" to reconcile the differences. Email out the\n result.\n\nThe result is a sequence of snapshots that have been _tested_ to work\ncorrectly. Now compare the svn workflow I briefly used at work:\n\n 1. svn update\n 2. hack hack hack\n 3. svn update\n 4. hack hack hack\n 5. svn update\n 6. hack hack hack\n 7. send out a patch for feedback\n\nNow another person wants to test the patch. So she tries:\n\n 1. svn update\n 2. Apply patch with \"patch -p1\".\n\nThe result applies okay and works great. So:\n\n 8. svn update\n 9. ... test ...\n 10. svn commit\n\nUnfortunately, the version committed (1) does not reflect the\ndevelopment history and (2) is not even tested, if changes\nhappened in trunk between step 9 and step 10.\n\nThat is, letting projects briefly diverge from upstream\n\n - avoids unnecessary interruptions to work;\n\n - allows the development history to be published, even when that was\n \"first write some code, then tweak it to match the new API\";\n\n - increases the likelihood that each commited revision actually\n works, making later mining for the code that introduced a feature\n or bug (\"git bisect\") much easier.\n\nOf course in the opposite direction is\n\n - changes to workflow can be hard for a team to adjust to\n\n(i.e., \"don't fix what isn't broken\").\n\nSorry, that ended up more longwinded than I hoped. Still,\nhope that helps.\n\nRegards,\nJonathan\n"},{"id":"157888","messageId":"20101212150929.GA23298@nibiru.local","threadId":"25997","inReplyTo":"1291829983410-5816069.post@n2.nabble.com","subject":"Re: Push to all repositories","fromName":"Enrico Weigelt","fromEmail":"weigelt@metux.de","sentAt":"2010-12-12T15:09:30Z","receivedAt":"2010-12-12T15:09:30Z","isPatch":false,"sender":{"key":"weigelt@metux.de","avatar":null},"body":"* Kevin Sheedy wrote:\n\nHi,\n\n> Clearcase has a great solution to this, \"dynamic views\". Whenever I check in\n> some code, the whole team magically get's my changes straight away.\n> Normally, they don't even notice, they're just forced to stay in sync. This\n> drastically reduces the number of 'code conflicts' where people make changes\n> to 'stale' files. This enforces the practise of \"catching errors early\". It\n> also keeps developers \"honest\" as they have to keep the quality of their\n> checkins high lest they get shouted at by the rest of the team.\n\nAre you sure you *really* want this ? \nI'd strongly advise against that.\n\nBetter have some central branch (maybe on a dedicated remote)\nwhere everybody can push to, and the others fork off from there\nand frequently rebase or merge if they like.\n\n\nMy preferred workflow is to have per-issue branches (eg. per bug,\nper feature, etc), which frequently get rebased to the mainline\nand are only pushed upwards if they're finished (IOW: only one\nperson is actively working on an small issue at a time, others\nmay just read but dont write). Once some issue branch seems to\nbe ready, it gets rebased to latest master and cleaned up, others\nmight do some reviews and if it passed all tests (and only then!)\nit gets pushed upwards.\n\n\ncu\n-- \n----------------------------------------------------------------------\n Enrico Weigelt, metux IT service -- http://www.metux.de/\n\n phone: +49 36207 519931 email: weigelt@metux.de\n mobile: +49 151 27565287 icq: 210169427 skype: nekrad666\n----------------------------------------------------------------------\n Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme\n----------------------------------------------------------------------\n"},{"id":"158812","messageId":"20110102095425.GA7061@nibiru.local","threadId":"25997","inReplyTo":"20101209195204.GB6884@burratino","subject":"Re: Push to all repositories","fromName":"Enrico Weigelt","fromEmail":"weigelt@metux.de","sentAt":"2011-01-02T09:54:25Z","receivedAt":"2011-01-02T09:54:25Z","isPatch":false,"sender":{"key":"weigelt@metux.de","avatar":null},"body":"* Jonathan Nieder wrote:\n\n> Consider a project in a patches+tarballs workflow. It begins like\n> this:\n> \n> 1. Acquire a tarball with the version you want to base your work on.\n> 2. Untar.\n> 3. Copy the result to save the current state.\n> 4. Test it.\n> 5. Fix a bug or add a feature.\n> 6. Make a patch with \"diff -pruN\"\n> 7. Return to step 3.\n> ...\n> 8. Looks good; email out the patches to get some feedback.\n> \n> Now another person wants to test the patches; so she tries:\n> \n> 1. Acquire a tarball with the version you want to test against.\n> 2. Untar.\n> 3. Apply patches with \"patch -p1\".\n> \n> Wait a second --- the patches don't apply! Or worse, they\n> apply but the result is broken. Okay:\n> \n> 4. Complain to the patch author.\n> \n> Finally the patch author has more work to do:\n> \n> 9. Acquire a newer tarball, and use either \"patch --reject-file\"\n> or rcs \"merge\" to reconcile the differences. Email out the\n> result.\n\nCompared to git:\n\n1. Clone repo and checkout the desired version\n2. Fix a bug or add a feature and commit to your local branch\n3. Do your tests and cleanups (eg. cleanups w/ interactive rebase)\n3. Push your branch to some place others can catch it and\n announce it to others\n\nNow another person wants to test your version:\n\n1. Clone your repo and checkout your branch.\n--> there is nothing that could fail to apply - everything's consistant\n by design (assuming the repo was cleanly cloned ;-o)\n2. Possibly become an author yourself:\n a. rebase to a newer upstream version\n --> same as above\n\n> The result is a sequence of snapshots that have been _tested_ to work\n> correctly. Now compare the svn workflow I briefly used at work:\n> \n> 1. svn update\n> 2. hack hack hack\n> 3. svn update\n> 4. hack hack hack\n> 5. svn update\n> 6. hack hack hack\n> 7. send out a patch for feedback\n\nSVN has a quite bad idea of branches and isn't even near to support\nthings like rebasing anyhow.\n\n> Unfortunately, the version committed (1) does not reflect the\n> development history and (2) is not even tested, if changes\n> happened in trunk between step 9 and step 10.\n\nThe idea of having everything in a big trunk is, aehm, quite suboptimal.\nBetter: have each issue in its own branch, that gets rebased to the\nmainline frequently and merged back there when properly tested.\n\n> Of course in the opposite direction is\n> \n> - changes to workflow can be hard for a team to adjust to\n> \n> (i.e., \"don't fix what isn't broken\").\n\nWell, many people tend to stick in old ideas (including workflows),\nno matter what newer developments are made. I currently have to cope\nwith that in an customer project: most of the people here don't even\nconsider using branches since the only vcs'es they know have no really\nusable support for this (TFS, etc ;-o), and they refuse to learn\nsomething new as long as their old way seems to work somehow (no matter\nof costs). I've estimated the productivity loss caused by sticking\nbackwards cruft like TFS on factors of 5..10 - nobody cares.\n(actually, not really bad for me: the longer it takes, the more \nmoney I earn ;-P)\n\n\ncu\n-- \n----------------------------------------------------------------------\n Enrico Weigelt, metux IT service -- http://www.metux.de/\n\n phone: +49 36207 519931 email: weigelt@metux.de\n mobile: +49 151 27565287 icq: 210169427 skype: nekrad666\n----------------------------------------------------------------------\n Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme\n----------------------------------------------------------------------\n"}]}