{"thread":{"id":"20706","subject":"Pulling one commit at a time.","startedAt":"2009-08-23T16:48:16Z","lastAt":"2009-08-24T19:08:19Z","messageCount":20,"participants":["Sanjiv Gupta","Alex Riesen","Sam Vilain","Adam Brewster","Nanako Shiraishi","Junio C Hamano","Matthieu Moy","Avery Pennarun","David Aguilar","Kai Blin","Sean Estabrooks","Erik Faye-Lund","skillzero@gmail.com"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"121566","messageId":"4A9172D0.6030507@microchip.com","threadId":"20706","inReplyTo":"F536B7C316F9474E9F7091239725AC9A02FA7F44@CHN-CL-MAIL01.mchp-main.com","subject":"Pulling one commit at a time.","fromName":"Sanjiv Gupta","fromEmail":"sanjiv.gupta@microchip.com","sentAt":"2009-08-23T16:48:16Z","receivedAt":"2009-08-23T16:48:16Z","isPatch":false,"sender":{"key":"sanjiv.gupta@microchip.com","avatar":null},"body":"Hi,\nThis is my first post here.\nI just wanted to know how can I pull one commit at a time from public \nrepository.\ne.g.\nwhen I first cloned from the public repo, it was at X. now it \nhas reached Y. I just want to pull x+1.\n \nhow to do that?\n \nIn SVN, we can just do $ svn update -r next_rev_num\n \nthanks\n- Sanjiv\n"},{"id":"121573","messageId":"81b0412b0908231311w483d737bncf8d4604cf7490db@mail.gmail.com","threadId":"20706","inReplyTo":"4A9172D0.6030507@microchip.com","subject":"Re: Pulling one commit at a time.","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2009-08-23T20:11:35Z","receivedAt":"2009-08-23T20:11:35Z","isPatch":false,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On Sun, Aug 23, 2009 at 18:48, Sanjiv Gupta<sanjiv.gupta@microchip.com> wrote:\n> when I first cloned from the public repo, it was at X. now it has reached Y.\n> I just want to pull x+1.\n>\n> how to do that?\n\nDepending on what you mean, it maybe either the what Git already\ndoes (a git fetch/git pull always transmits only the differences) or a\nsecurity risk and impossible (an ability to fetch an arbitrary commit\nbypasses checks imposed by the reference names published).\n"},{"id":"121577","messageId":"c376da900908231317j58e31f78l85bf9132d5bd0e1e@mail.gmail.com","threadId":"20706","inReplyTo":"4A9172D0.6030507@microchip.com","subject":"Re: Pulling one commit at a time.","fromName":"Adam Brewster","fromEmail":"adambrewster@gmail.com","sentAt":"2009-08-23T20:17:07Z","receivedAt":"2009-08-23T20:17:07Z","isPatch":false,"sender":{"key":"adambrewster@gmail.com","avatar":"https://avatars.githubusercontent.com/u/223816?v=4"},"body":"On Sun, Aug 23, 2009 at 12:48 PM, Sanjiv\nGupta<sanjiv.gupta@microchip.com> wrote:\n> Hi,\n> This is my first post here.\n> I just wanted to know how can I pull one commit at a time from public\n> repository.\n> e.g.\n> when I first cloned from the public repo, it was at X. now it has reached Y.\n> I just want to pull x+1.\n>\n> how to do that?\n>\n> In SVN, we can just do $ svn update -r next_rev_num\n>\n\nGit is a distributed system and handles branching much differently\nthan svn, so pull x+1 sounds like a funny request to git.\n\nYou could use `git fetch` to get the history from the remote\nrepository, then use `git log` or `gitk` to find the name of the\ncommit you're interested in, and use `git checkout` to switch to that\nbranch or `git merge` to merge the changes from the next commit into\nyour current branch.\n\nPerhaps it would help if we knew why you only wanted to fetch one\ncommit at a time.\n\nAdam\n"},{"id":"121576","messageId":"1251058765.7438.2.camel@maia.lan","threadId":"20706","inReplyTo":"4A9172D0.6030507@microchip.com","subject":"Re: Pulling one commit at a time.","fromName":"Sam Vilain","fromEmail":"sam@vilain.net","sentAt":"2009-08-23T20:19:25Z","receivedAt":"2009-08-23T20:19:25Z","isPatch":false,"sender":{"key":"sam@vilain.net","avatar":"https://gravatar.com/avatar/8fc840ca854dbf6f7065b4335e3b934951c1dca3b11db688e95e471901f8f4a8?d=mp&s=160"},"body":"On Sun, 2009-08-23 at 22:18 +0530, Sanjiv Gupta wrote:\n> Hi,\n> This is my first post here.\n> I just wanted to know how can I pull one commit at a time from public \n> repository.\n> e.g.\n> when I first cloned from the public repo, it was at X. now it \n> has reached Y. I just want to pull x+1.\n>  \n> how to do that?\n>  \n> In SVN, we can just do $ svn update -r next_rev_num\n\ngit pull or git pull --rebase\n\nWhy not find a tutorial or go through the user manual.\n\nSam\n"},{"id":"121585","messageId":"20090824060710.6117@nanako3.lavabit.com","threadId":"20706","inReplyTo":"4A9172D0.6030507@microchip.com","subject":"Re: Pulling one commit at a time.","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-08-23T21:07:10Z","receivedAt":"2009-08-23T21:07:10Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Sanjiv Gupta <sanjiv.gupta@microchip.com>\n\n> I just wanted to know how can I pull one commit at a time from public\n> repository.\n> e.g.\n> when I first cloned from the public repo, it was at X. now it has\n> reached Y. I just want to pull x+1.\n\nWhen your histories look like this:\n\n      A                 your 'master'\n     /\n ---X---U---V---W---Y   public 'master' (your 'origin')\n\ninstead of creating a single merge like this with \"git pull\":\n\n      A---------------M your 'master' (fully merges 'origin')\n     /               / \n ---X---U---V---W---Y   public 'master'\n\nyou want to create a history like this?\n\n      A---J             your 'master' (lacks V, W and Y)\n     /   /\n ---X---U---V---W---Y   public 'master'\n\nFor that, you can fetch first.\n\n git fetch origin\n\nThen look at the history in gitk\n\n gitk master origin\n\nAnd find the commit you are interested in merging (U in the above picture). And merge it.\n\n git merge origin~3\n\nReplace \"origin~3\" in the example above with whatever commit you want to merge the entire history leading to it.\n\nYou can repeat this final step as many times you want. For example, if you want create a history like this:\n\n      A---J---K---L---M your 'master'\n     /   /   /   /   / \n ---X---U---V---W---Y   public 'master'\n\nyou can do so by repeating the last step for V, W and Y in turn.\n\nIn general the public history isn't necessarily a single straight line like this picture and it doesn't make sense to merge one at a time for all the commits on the public branch, but if that is what you really want to do, you can do so.\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"121598","messageId":"7vr5v2qhws.fsf@alter.siamese.dyndns.org","threadId":"20706","inReplyTo":"20090824060710.6117@nanako3.lavabit.com","subject":"Re: Pulling one commit at a time.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-08-23T22:33:55Z","receivedAt":"2009-08-23T22:33:55Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nanako Shiraishi <nanako3@lavabit.com> writes:\n\n> When your histories look like this:\n>\n>       A                 your 'master'\n>      /\n>  ---X---U---V---W---Y   public 'master' (your 'origin')\n>\n> ... you can fetch first.\n>\n>  git fetch origin\n>\n> Then look at the history in gitk\n>\n>  gitk master origin\n>\n> And find the commit you are interested in merging (U in the above\n> picture). And merge it.\n>\n>  git merge origin~3\n>\n> Replace \"origin~3\" in the example above with whatever commit you want to\n> merge the entire history leading to it.\n\nA good description.  Thanks, Nana.\n\nNovice readers should notice the careful wording used here.  She says\n\"merge the entire history leading to it\" instead of simply \"merge the\ncommit\".  Merging a commit in git always means merging the entire history\nleading to that commit, so they mean the same thing to people who know git\nwell, but it avoids a misunderstanding that, if you did\n\n    $ git merge V\n\nit might apply the effect of only V, ignoring what U did, on top of your\ncurrent state A.  It doesn't.\n\n       A-------M         your 'master'\n      /       / \n  ---X---U---V---W---Y   public 'master' (your 'origin')\n\nTo create a commit that has only the effect of a single commit, you would\nneed to cherry-pick it.\n\n    $ git cherry-pick V\n\nwill give you\n\n       A-------V'        your 'master'\n      /\n  ---X---U---V---W---Y   public 'master' (your 'origin')\n\nwhere \"git diff A V'\" is a moral equivalent of \"git diff U V\".\n"},{"id":"121616","messageId":"4A92318F.6050105@microchip.com","threadId":"20706","inReplyTo":"20090824060710.6117@nanako3.lavabit.com","subject":"Re: Pulling one commit at a time.","fromName":"Sanjiv Gupta","fromEmail":"sanjiv.gupta@microchip.com","sentAt":"2009-08-24T06:22:07Z","receivedAt":"2009-08-24T06:22:07Z","isPatch":false,"sender":{"key":"sanjiv.gupta@microchip.com","avatar":null},"body":"Nanako Shiraishi wrote:\n> Quoting Sanjiv Gupta <sanjiv.gupta@microchip.com>\n>\n>   \n>> I just wanted to know how can I pull one commit at a time from public\n>> repository.\n>> e.g.\n>> when I first cloned from the public repo, it was at X. now it has\n>> reached Y. I just want to pull x+1.\n>>     \n>\n> When your histories look like this:\n>\n>       A                 your 'master'\n>      /\n>  ---X---U---V---W---Y   public 'master' (your 'origin')\n>\n> instead of creating a single merge like this with \"git pull\":\n>\n>       A---------------M your 'master' (fully merges 'origin')\n>      /               / \n>  ---X---U---V---W---Y   public 'master'\n>\n> you want to create a history like this?\n>\n>       A---J             your 'master' (lacks V, W and Y)\n>      /   /\n>  ---X---U---V---W---Y   public 'master'\n>\n> For that, you can fetch first.\n>\n>  git fetch origin\n>\n> Then look at the history in gitk\n>\n>  gitk master origin\n>\n> And find the commit you are interested in merging (U in the above picture). And merge it.\n>\n>  git merge origin~3\n>\n> Replace \"origin~3\" in the example above with whatever commit you want to merge the entire history leading to it.\n>\n> You can repeat this final step as many times you want. For example, if you want create a history like this:\n>\n>       A---J---K---L---M your 'master'\n>      /   /   /   /   / \n>  ---X---U---V---W---Y   public 'master'\n>\n> you can do so by repeating the last step for V, W and Y in turn.\n>\n> In general the public history isn't necessarily a single straight line like this picture and it doesn't make sense to merge one at a time for all the commits on the public branch, but if that is what you really want to do, you can do so.\n>\n>   \nExcellent description. Thanks for that. I want to merge commits one by \none because I want to run a regression suite on each commit and \ntherefore know if any one is causing failures.\n\n- Sanjiv\n"},{"id":"299110","messageId":"200908240946.52813.kai@samba.org","threadId":"20706","inReplyTo":"4A92318F.6050105@microchip.com","subject":"Re: Pulling one commit at a time.","fromName":"Kai Blin","fromEmail":"kai@samba.org","sentAt":"2009-08-24T07:46:46Z","receivedAt":"2009-08-24T07:46:46Z","isPatch":false,"sender":{"key":"kai@samba.org","avatar":"https://gravatar.com/avatar/bc7698f10d926406cee9c7bad46d2b345249777dadd9ece4501f6f2384a03e52?d=mp&s=160"},"body":"On Monday 24 August 2009 08:22:07 Sanjiv Gupta wrote:\n\n> > In general the public history isn't necessarily a single straight line\n> > like this picture and it doesn't make sense to merge one at a time for\n> > all the commits on the public branch, but if that is what you really want\n> > to do, you can do so.\n>\n> Excellent description. Thanks for that. I want to merge commits one by\n> one because I want to run a regression suite on each commit and\n> therefore know if any one is causing failures.\n\nWhat I do for a case like this is using rebase. I'm not sure if I get the \nexplanation right enough to please all the git gurus on the list, but I'll \ntry. What this basically does is to back out all the commits you did on your \nbranch to the point you diverged from the branch you're rebasing on now.\n\nSo assuming you had a structure like this:\n\n           your 'master' HEAD\n             |\n     A---B---C\n    /\n---X---U---V---W---Y\n                   |\n                public 'master' HEAD\n\ngit would back out commits A-C, so your local branch HEAD would be at X. Then, \nif forwards your branch to the branch you're rebasing on, so your local \nbranch HEAD is at Y now, like the public branch HEAD.\n\nAfter that, git applies all of your patches back to your local branch, \nproducing a tree that looks like this:\n\n                           your 'master' HEAD\n                             |\n                     A---B---C\n                    /\n---X---U---V---W---Y\n                   |\n              public 'master' head\n\nPersonally I prefer that solution as it keeps the history linear. Of course \nthis means that all of your commits change sha1s, and you should not do this \non public branches with tags. But if you're still developing, it's much \neasier to wrap your head around a history like this. It's also nice to \npresent feature branches to other people, as all of your commits are in one \nblock, without lots of annoying merge commits between them.\n\nrebase also handles more complicated cases of merging, but from the way I \nunderstood your issue, this should already help.\n\nCheers,\nKai\n-- \nKai Blin\nWorldForge developer  http://www.worldforge.org/\nWine developer        http://wiki.winehq.org/KaiBlin\nSamba team member     http://www.samba.org/samba/team/\n--\nWill code for cotton.\n"},{"id":"299111","messageId":"4A92476A.4060205@microchip.com","threadId":"20706","inReplyTo":"200908240946.52813.kai@samba.org","subject":"Re: Pulling one commit at a time.","fromName":"Sanjiv Gupta","fromEmail":"sanjiv.gupta@microchip.com","sentAt":"2009-08-24T07:55:22Z","receivedAt":"2009-08-24T07:55:22Z","isPatch":false,"sender":{"key":"sanjiv.gupta@microchip.com","avatar":null},"body":"Kai Blin wrote:\n> On Monday 24 August 2009 08:22:07 Sanjiv Gupta wrote:\n>\n>   \n>>> In general the public history isn't necessarily a single straight line\n>>> like this picture and it doesn't make sense to merge one at a time for\n>>> all the commits on the public branch, but if that is what you really want\n>>> to do, you can do so.\n>>>       \n>> Excellent description. Thanks for that. I want to merge commits one by\n>> one because I want to run a regression suite on each commit and\n>> therefore know if any one is causing failures.\n>>     \n>\n> What I do for a case like this is using rebase. I'm not sure if I get the \n> explanation right enough to please all the git gurus on the list, but I'll \n> try. What this basically does is to back out all the commits you did on your \n> branch to the point you diverged from the branch you're rebasing on now.\n>\n> So assuming you had a structure like this:\n>\n>            your 'master' HEAD\n>              |\n>      A---B---C\n>     /\n> ---X---U---V---W---Y\n>                    |\n>                 public 'master' HEAD\n>\n> git would back out commits A-C, so your local branch HEAD would be at X. Then, \n> if forwards your branch to the branch you're rebasing on, so your local \n> branch HEAD is at Y now, like the public branch HEAD.\n>\n> After that, git applies all of your patches back to your local branch, \n> producing a tree that looks like this:\n>\n>                            your 'master' HEAD\n>                              |\n>                      A---B---C\n>                     /\n> ---X---U---V---W---Y\n>                    |\n>               public 'master' head\n>\n> Personally I prefer that solution as it keeps the history linear. Of course \n> this means that all of your commits change sha1s, and you should not do this \n> on public branches with tags. But if you're still developing, it's much \n> easier to wrap your head around a history like this. It's also nice to \n> present feature branches to other people, as all of your commits are in one \n> block, without lots of annoying merge commits between them.\n>\n> rebase also handles more complicated cases of merging, but from the way I \n> understood your issue, this should already help.\n>\n> Cheers,\n> Kai\n>   \nThanks Kai.\nWhat I would like is to \"test *every* commit\" available in the public \nmaster. There would be no local changes or commits that aren't pushed in \nthe private copy.\nSo I just want to clone one copy from the public master and then just \nkeep pulling commits from the public master one by one and run \nregressions on each one.\n\nIt's a damn simple thing in SVN world.\n$ svn info will give you the current version you are at, assume it is \n\"cur_rev\"\n$ svn update -r `expr $cur_rev + 1`\n$ build\n$ test\n\nThanks,\n- Sanjiv\n\n"},{"id":"299112","messageId":"BLU0-SMTP3926FD52F3B0ED67F486AAAEF90@phx.gbl","threadId":"20706","inReplyTo":"4A92476A.4060205@microchip.com","subject":"Re: Pulling one commit at a time.","fromName":"Sean Estabrooks","fromEmail":"seanlkml@sympatico.ca","sentAt":"2009-08-24T08:20:18Z","receivedAt":"2009-08-24T08:20:18Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Mon, 24 Aug 2009 13:25:22 +0530\nSanjiv Gupta <sanjiv.gupta@microchip.com> wrote:\n\nHi Sanjiv,\n\n> What I would like is to \"test *every* commit\" available in the public \n> master. There would be no local changes or commits that aren't pushed in \n> the private copy.\n> So I just want to clone one copy from the public master and then just \n> keep pulling commits from the public master one by one and run \n> regressions on each one.\n\nThere's no reason to ask for the commits from the public master one by\none.  You can download them all in one operation.   After that it is\na local operation to checkout each new commit and build-test it.  This\nis more efficient than needing a network operation to get each commit\nindividually.\n\nAs an aside, you might not really need to test each and every commit.\nIt is likely enough to just test the most recent commit since it is\nbuilt on top of all the commits that came before it.  Essentially\nyou'd be testing all the new commits at once and only need to test\nmore commits (git bisect) if you found a regression with that first\ntest.\n\n> It's a damn simple thing in SVN world.\n\nWith Git you have a complete local copy of the history.  Once you're\nup to date with remote master you can checkout each new commit at \nyour leisure pretty damn simply ;o)\n\nCheers,\nSean\n"},{"id":"299113","messageId":"40aa078e0908240120o36004f78m52aa34c8a338854c@mail.gmail.com","threadId":"20706","inReplyTo":"4A92476A.4060205@microchip.com","subject":"Re: Pulling one commit at a time.","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2009-08-24T08:20:54Z","receivedAt":"2009-08-24T08:20:54Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Mon, Aug 24, 2009 at 9:55 AM, Sanjiv Gupta<sanjiv.gupta@microchip.com> wrote:\n> It's a damn simple thing in SVN world.\n> $ svn info will give you the current version you are at, assume it is\n> \"cur_rev\"\n> $ svn update -r `expr $cur_rev + 1`\n> $ build\n> $ test\n\nI guess you could do it something like this. Unlike your example, this\nprocesses all new commits, not just the next one.\n\n$ git fetch origin master\n$ for c in $(git rev-list HEAD..FETCH_HEAD); do\n$ \tgit checkout $c\n$ \tbuild\n$ \ttest\n$ done\n$ git merge FETCH_HEAD\n\n-- \nErik \"kusma\" Faye-Lund\nkusmabite@gmail.com\n(+47) 986 59 656\n"},{"id":"299114","messageId":"40aa078e0908240122j480a6470w346af5f67df27611@mail.gmail.com","threadId":"20706","inReplyTo":"40aa078e0908240120o36004f78m52aa34c8a338854c@mail.gmail.com","subject":"Re: Pulling one commit at a time.","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2009-08-24T08:22:26Z","receivedAt":"2009-08-24T08:22:26Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"> $ git merge FETCH_HEAD\n\nUhm, of course, you'd have to reattach HEAD to your branch before\nmerging. My bad ;)\n\n-- \nErik \"kusma\" Faye-Lund\nkusmabite@gmail.com\n(+47) 986 59 656\n"},{"id":"298989","messageId":"vpqtyzxhaz8.fsf@bauges.imag.fr","threadId":"20706","inReplyTo":"4A92476A.4060205@microchip.com","subject":"Re: Pulling one commit at a time.","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-08-24T08:28:27Z","receivedAt":"2009-08-24T08:28:27Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Sanjiv Gupta <sanjiv.gupta@microchip.com> writes:\n\n> What I would like is to \"test *every* commit\" available in the\n> public master.\n\nThen, you don't want to _merge_ each of them, you want to _fetch_ and\ntest each of them (Erik Faye-Lund's reply gives a solution for that).\n\nFetching is about getting existing commits from another repository,\nwhile merging is about creating new commits.\n\n-- \nMatthieu\n"},{"id":"299115","messageId":"2729632a0908240133t12eaafd5oe8d50af6d6eec566@mail.gmail.com","threadId":"20706","inReplyTo":"4A92476A.4060205@microchip.com","subject":"Re: Pulling one commit at a time.","fromName":"","fromEmail":"skillzero@gmail.com","sentAt":"2009-08-24T08:33:46Z","receivedAt":"2009-08-24T08:33:46Z","isPatch":false,"sender":{"key":"skillzero@gmail.com","avatar":null},"body":"On Mon, Aug 24, 2009 at 12:55 AM, Sanjiv\nGupta<sanjiv.gupta@microchip.com> wrote:\n\n> What I would like is to \"test *every* commit\" available in the public\n> master. There would be no local changes or commits that aren't pushed in the\n> private copy.\n> So I just want to clone one copy from the public master and then just keep\n> pulling commits from the public master one by one and run regressions on\n> each one.\n>\n> It's a damn simple thing in SVN world.\n> $ svn info will give you the current version you are at, assume it is\n> \"cur_rev\"\n> $ svn update -r `expr $cur_rev + 1`\n> $ build\n> $ test\n\nI'm not sure if this is the best way, but you can use git fetch to get\nthe latest stuff from the server without merging it then you can merge\nfrom origin/master (i.e. the server) into your local master, one\ncommit at a time, and verify at each step:\n\n$ git merge `git log --format=%h master..origin/master | sed '$!d'`\n$ build\n$ test\n"},{"id":"298990","messageId":"vpqfxbhd2o4.fsf@bauges.imag.fr","threadId":"20706","inReplyTo":"2729632a0908240133t12eaafd5oe8d50af6d6eec566@mail.gmail.com","subject":"Re: Pulling one commit at a time.","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-08-24T08:41:31Z","receivedAt":"2009-08-24T08:41:31Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"skillzero@gmail.com writes:\n\n> On Mon, Aug 24, 2009 at 12:55 AM, Sanjiv\n> Gupta<sanjiv.gupta@microchip.com> wrote:\n>\n>> What I would like is to \"test *every* commit\" available in the public\n>> master. There would be no local changes or commits that aren't pushed in the\n>> private copy.\n>> So I just want to clone one copy from the public master and then just keep\n>> pulling commits from the public master one by one and run regressions on\n>> each one.\n>>\n>> It's a damn simple thing in SVN world.\n>> $ svn info will give you the current version you are at, assume it is\n>> \"cur_rev\"\n>> $ svn update -r `expr $cur_rev + 1`\n>> $ build\n>> $ test\n>\n> I'm not sure if this is the best way, but you can use git fetch to get\n> the latest stuff from the server without merging it then you can merge\n> from origin/master (i.e. the server) into your local master, one\n> commit at a time, and verify at each step:\n\nSee my other reply, but I really don't think you want to _merge_ one\ncommit at a time. This would not mean \"test each commit\" but \"test the\ninteraction between any two commits\", which few people would care\nabout.\n\nThe example above in SVN doesn't merge each commit, it just walks\nhistory (assuming the history is linear, the example wouldn't be as\nsimple if it had to walk /branches/* too). To continue the analogy,\nmerging commits one by one in Git would be more or less the equivalent\nin SVN of:\n\n$ svn status\n# Hmm, OK, I have stuff to commit.\n$ test\n# Yes, it works. But do my changes work too on top of the previous\n# commits?\n$ while ...; do\n    svn update $(($cur_rev - 1))\n    build\n    test\n  done\n# If so, then\n$ svn update\n$ svn commit\n\nThat is: test the interaction between your new change with any other\nchanges in the repository. 'never seen anyone interested by such\nthing, but why not ;-).\n\n-- \nMatthieu\n"},{"id":"298991","messageId":"20090824102242.GA70861@gmail.com","threadId":"20706","inReplyTo":"4A92318F.6050105@microchip.com","subject":"Re: Pulling one commit at a time.","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2009-08-24T10:22:43Z","receivedAt":"2009-08-24T10:22:43Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Mon, Aug 24, 2009 at 11:52:07AM +0530, Sanjiv Gupta wrote:\n> Excellent description. Thanks for that. I want to merge commits one by  \n> one because I want to run a regression suite on each commit and  \n> therefore know if any one is causing failures.\n\n'git bisect' is your friend.\n\nIf your developers are disciplined and test each change as they\ncommit it then you're going to have fewer problems.\n\nIf they aren't, then make 'em send you patches.  Then you can\nat least 'git am' each one and run the tests at each step,\nincluding the critical steps where you merge various topics\ntogether.\n\nI'm not sure what exactly you're trying to accomplish, though.\nI'm just making guesses without you telling us more.\n\nAre you trying to do post-mortem change-that-introduced-bug\nfinding (git bisect), commit-time bug prevention\n(patch-based workflows, using git commit hooks to disallow\ncommits that fail the tests, etc), or is it something\ncompletely different?\n\n\nHTH,\n\n-- \n\t\tDavid\n"},{"id":"299116","messageId":"4A92703E.90007@microchip.com","threadId":"20706","inReplyTo":"20090824102242.GA70861@gmail.com","subject":"Re: Pulling one commit at a time.","fromName":"Sanjiv Gupta","fromEmail":"sanjiv.gupta@microchip.com","sentAt":"2009-08-24T10:49:34Z","receivedAt":"2009-08-24T10:49:34Z","isPatch":false,"sender":{"key":"sanjiv.gupta@microchip.com","avatar":null},"body":"David Aguilar wrote:\n> On Mon, Aug 24, 2009 at 11:52:07AM +0530, Sanjiv Gupta wrote:\n>   \n>> Excellent description. Thanks for that. I want to merge commits one by  \n>> one because I want to run a regression suite on each commit and  \n>> therefore know if any one is causing failures.\n>>     \n>\n> 'git bisect' is your friend.\n>\n> If your developers are disciplined and test each change as they\n> commit it then you're going to have fewer problems.\n>\n> If they aren't, then make 'em send you patches.  Then you can\n> at least 'git am' each one and run the tests at each step,\n> including the critical steps where you merge various topics\n> together.\n>\n> I'm not sure what exactly you're trying to accomplish, though.\n> I'm just making guesses without you telling us more.\n>\n> Are you trying to do post-mortem change-that-introduced-bug\n> finding (git bisect), commit-time bug prevention\n> (patch-based workflows, using git commit hooks to disallow\n> commits that fail the tests, etc), or is it something\n> completely different?\n>\n>\n> HTH,\n>\n>   \nThanks everyone for the overwhelming response.\nI was looking for post-mortem change-that-introduced-bug.\nIt's also called \"buildbot\" in other terms, which sends you an email \nwith the details of the \"culprit\" commit as soon as it introduces a bug.\n\n- Sanjiv\n\n\n-\n\n"},{"id":"121622","messageId":"vpqskfhbhcz.fsf@bauges.imag.fr","threadId":"20706","inReplyTo":"4A92703E.90007@microchip.com","subject":"Re: Pulling one commit at a time.","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@imag.fr","sentAt":"2009-08-24T11:07:08Z","receivedAt":"2009-08-24T11:07:08Z","isPatch":false,"sender":{"key":"git@matthieu-moy.fr","avatar":"https://avatars.githubusercontent.com/u/14709?v=4"},"body":"Sanjiv Gupta <sanjiv.gupta@microchip.com> writes:\n\n> I was looking for post-mortem change-that-introduced-bug.\n\nIf so, then you don't need to test every commit. As David mentionned,\n\"git bisect\" is your friend, and will do a binary search, finding the\nculprit commit much more efficiently (run the testsuite log(n) times\ninstead of n times).\n\nOTOH, if you want some kind of quality insurance (i.e. check that\nevery commit is OK, including the case where a commit introduces a\nbug, and the next one fixes it), bisect is rather helpless.\n\n-- \nMatthieu\n"},{"id":"121657","messageId":"32541b130908241119t1b969d30q8c8b484481f30ace@mail.gmail.com","threadId":"20706","inReplyTo":"4A92318F.6050105@microchip.com","subject":"Re: Pulling one commit at a time.","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2009-08-24T18:19:56Z","receivedAt":"2009-08-24T18:19:56Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Mon, Aug 24, 2009 at 6:22 AM, Sanjiv Gupta<sanjiv.gupta@microchip.com> wrote:\n> Excellent description. Thanks for that. I want to merge commits one by one\n> because I want to run a regression suite on each commit and therefore know\n> if any one is causing failures.\n\nHi Sanjiv,\n\n'git bisect' is an even better way to do this, in my experience.  I\nwrote a program (http://github.com/apenwarr/gitbuilder/) that\nautomatically runs regression tests against all the new versions on\nall the new branches.  It then publishes the results on a web page and\nvia RSS.\n\ngitbuilder does take a shortcut: if commit x passes and commit x+10\npasses, it doesn't bother to test commit x+1..9.  However, if x+10\nfails, it bisects automatically to find the first commit that caused a\nfailure.  You could disable this shortcut easily enough, however.\n\nHave fun,\n\nAvery\n"},{"id":"121664","messageId":"4A92E523.50504@microchip.com","threadId":"20706","inReplyTo":"32541b130908241119t1b969d30q8c8b484481f30ace@mail.gmail.com","subject":"Re: Pulling one commit at a time.","fromName":"Sanjiv Gupta","fromEmail":"sanjiv.gupta@microchip.com","sentAt":"2009-08-24T19:08:19Z","receivedAt":"2009-08-24T19:08:19Z","isPatch":false,"sender":{"key":"sanjiv.gupta@microchip.com","avatar":null},"body":"Avery Pennarun wrote:\n> On Mon, Aug 24, 2009 at 6:22 AM, Sanjiv Gupta<sanjiv.gupta@microchip.com> wrote:\n>   \n>> Excellent description. Thanks for that. I want to merge commits one by one\n>> because I want to run a regression suite on each commit and therefore know\n>> if any one is causing failures.\n>>     \n>\n> Hi Sanjiv,\n>\n> 'git bisect' is an even better way to do this, in my experience.  I\n> wrote a program (http://github.com/apenwarr/gitbuilder/) that\n> automatically runs regression tests against all the new versions on\n> all the new branches.  It then publishes the results on a web page and\n> via RSS.\n>\n> gitbuilder does take a shortcut: if commit x passes and commit x+10\n> passes, it doesn't bother to test commit x+1..9.  \nEven, I won't need to run in between commits in that case.\nWhat I wanted to do is to\n1. off load this job to a script which sends an email to the developer \nwho broke something,\n2. schedule that script\n3. and sit back relaxed myself.\n\nLooks like you already have the tool. Thanks.\n\nBTW, git is not git, it's great.\n\nthanks to everybody who replied.\n- Sanjiv\n\n> However, if x+10\n> fails, it bisects automatically to find the first commit that caused a\n> failure.  You could disable this shortcut easily enough, however.\n>\n> Have fun,\n>\n> Avery\n>   \n"}]}