{"thread":{"id":"24538","subject":"Recommended work flow with git to send in patches","startedAt":"2010-07-27T15:31:24Z","lastAt":"2010-07-28T23:30:33Z","messageCount":14,"participants":["Tong Sun","Ævar Arnfjörð Bjarmason","Ramkumar Ramachandra","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"146484","messageId":"AANLkTiksAOpFG3vGVGcbeZ0NcpQ5FbDjnZ7yDxUsAY_r@mail.gmail.com","threadId":"24538","inReplyTo":null,"subject":"Recommended work flow with git to send in patches","fromName":"Tong Sun","fromEmail":"suntong@cpan.org","sentAt":"2010-07-27T15:31:24Z","receivedAt":"2010-07-27T15:31:24Z","isPatch":false,"sender":{"key":"suntong@cpan.org","avatar":null},"body":"Hi,\n\nCompressing my \"life long story\" into a single question -- what's the\nrecommended work flow to work with git and send in patches, when\nupstream might be slow in respond, and require squashing relevant\npatches into one?\n\nYou can use my following message as a start point, and please answer\nmy last question, which I've been asking twice (in different ways)\nwith no answer.\n\nPlease CC me when replying.\n\nThanks\n\n---------- Forwarded message ----------\nFrom: Tong Sun \nDate: Sun, Jun 6, 2010 at 8:56 PM\nSubject: Working with git and sending in patches\nTo: grml-devel@ml.grml.org\n\n\nHi,\n\nJust trying to put all jigsaw puzzle together here. Please correct me\nif I'm wrong.\n\nFirst of all, philosophy for version control with git:\n\n. While developing, small/independent commits are good thing, so that\nit's easy to decouple different changes.\n\n. But when integrating something in a main branch, commits should contain all\nlogical/related changes.\n\nSteps (using grml-debootstrap as an example):\n\n- do initial git pull into grml-debootstrap\n\n  git pull git://git.grml.org/grml-debootstrap master\n\n- Go into grml-debootstrap and start a new branch\n\n  git checkout -b t/my-working-branch\n\n- work on the code, commit, hack, commit, hack, commit -- commit often\n& commit small\n\n- when AOK and need to integrate patches into main branch, squash all\npatches into one\n\n  git rebase -i origin/master\n\n- send in patches via email (to grml-devel@ml.grml.org)\n\n  git format-patch origin\n  git send-email --to grml-devel@ml.grml.org ...\n\nPlease correct me if anything above is wrong.\n\nNow, question, having done above, if I start to work some logically\nunrelated patches, what steps should I take? (I don't want 'git\nrebase' to pick up patches that I've already sent in).\n"},{"id":"146485","messageId":"AANLkTin-x01FrFWLD04um8xwKeb6vUjpqlG0S7Xnk85j@mail.gmail.com","threadId":"24538","inReplyTo":"AANLkTiksAOpFG3vGVGcbeZ0NcpQ5FbDjnZ7yDxUsAY_r@mail.gmail.com","subject":"Re: Recommended work flow with git to send in patches","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-07-27T15:35:54Z","receivedAt":"2010-07-27T15:35:54Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Tue, Jul 27, 2010 at 15:31, Tong Sun wrote:\n> - work on the code, commit, hack, commit, hack, commit -- commit often\n> & commit small\n\nSo far so good.\n\n> - when AOK and need to integrate patches into main branch, squash all\n> patches into one\n\nThat's just silly. Why is the policy to destroy commit information\nwhen submitting patches?\n"},{"id":"146486","messageId":"20100727153901.GA5351@kytes","threadId":"24538","inReplyTo":"AANLkTiksAOpFG3vGVGcbeZ0NcpQ5FbDjnZ7yDxUsAY_r@mail.gmail.com","subject":"Re: Recommended work flow with git to send in patches","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-07-27T15:39:03Z","receivedAt":"2010-07-27T15:39:03Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Tong,\n\nTong Sun writes:\n> Compressing my \"life long story\" into a single question -- what's the\n> recommended work flow to work with git and send in patches, when\n> upstream might be slow in respond, and require squashing relevant\n> patches into one?\n\nPersonally, I use `git symbolic-ref` to create a new branch without\nhistory, stage and create commits to send off to the list from there;\nit's also worth noting that I keep the branch to fixup my commits and\nre-roll after reviews.\n\n-- Ram\n"},{"id":"146487","messageId":"AANLkTikk_EZuGayD2yPqEhTyXS9YKHscwCF2NNjXwMdv@mail.gmail.com","threadId":"24538","inReplyTo":"AANLkTin-x01FrFWLD04um8xwKeb6vUjpqlG0S7Xnk85j@mail.gmail.com","subject":"Re: Recommended work flow with git to send in patches","fromName":"Tong Sun","fromEmail":"suntong@cpan.org","sentAt":"2010-07-27T15:43:02Z","receivedAt":"2010-07-27T15:43:02Z","isPatch":false,"sender":{"key":"suntong@cpan.org","avatar":null},"body":"On Tue, Jul 27, 2010 at 11:35 AM, Ævar Arnfjörð Bjarmason\n wrote:\n> On Tue, Jul 27, 2010 at 15:31, Tong Sun wrote:\n>> - work on the code, commit, hack, commit, hack, commit -- commit often\n>> & commit small\n>\n> So far so good.\n>\n>> - when AOK and need to integrate patches into main branch, squash all\n>> patches into one\n>\n> That's just silly. Why is the policy to destroy commit information\n> when submitting patches?\n\nSorry about the confusing. The original message was composed under the\ncondition that all patches are relevant patches that work together to\nform a big logical changes. I was required to do the squashing.\n\nthanks\n"},{"id":"146488","messageId":"AANLkTinEQKuxHD6MbXq43E=AWymebvoWXM5v2Tm6vejw@mail.gmail.com","threadId":"24538","inReplyTo":"20100727153901.GA5351@kytes","subject":"Re: Recommended work flow with git to send in patches","fromName":"Tong Sun","fromEmail":"suntong@cpan.org","sentAt":"2010-07-27T15:47:34Z","receivedAt":"2010-07-27T15:47:34Z","isPatch":false,"sender":{"key":"suntong@cpan.org","avatar":null},"body":"On Tue, Jul 27, 2010 at 11:39 AM, Ramkumar Ramachandra\n wrote:\n\n>> Compressing my \"life long story\" into a single question -- what's the\n>> recommended work flow to work with git and send in patches, when\n>> upstream might be slow in respond, and require squashing relevant\n>> patches into one?\n>\n> Personally, I use `git symbolic-ref` to create a new branch without\n> history, stage and create commits to send off to the list from there;\n> it's also worth noting that I keep the branch to fixup my commits and\n> re-roll after reviews.\n\nThanks a lot for the comment.\n\nCould you elaborate it a bit with actual commands, starting from 'git\npull git://remote/project master' please?\n\nI'm new to git and the above comment barely helps me to put all jigsaw\npuzzle together.\n\nthanks\n"},{"id":"146490","messageId":"20100727164500.GD5351@kytes","threadId":"24538","inReplyTo":"AANLkTinEQKuxHD6MbXq43E=AWymebvoWXM5v2Tm6vejw@mail.gmail.com","subject":"Re: Recommended work flow with git to send in patches","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-07-27T16:45:02Z","receivedAt":"2010-07-27T16:45:02Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Tong,\n\nTong Sun writes:\n> Thanks a lot for the comment.\n> \n> Could you elaborate it a bit with actual commands, starting from 'git\n> pull git://remote/project master' please?\n\n$ git symbolic-ref HEAD refs/heads/rollout\n$ rm .git/index # Git recreates it automatically anyway\n$ git add LICENSE\n$ git commit -m \"Add LICENSE\" # root commit\n$ # git add ... git commit cycle\n\n-- Ram\n"},{"id":"146495","messageId":"m339v4luk2.fsf@localhost.localdomain","threadId":"24538","inReplyTo":"20100727164500.GD5351@kytes","subject":"Re: Recommended work flow with git to send in patches","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-07-27T17:11:38Z","receivedAt":"2010-07-27T17:11:38Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Ramkumar Ramachandra writes:\n> Tong Sun writes:\n> > Thanks a lot for the comment.\n> > \n> > Could you elaborate it a bit with actual commands, starting from 'git\n> > pull git://remote/project master' please?\n> \n> $ git symbolic-ref HEAD refs/heads/rollout\n> $ rm .git/index # Git recreates it automatically anyway\n> $ git add LICENSE\n> $ git commit -m \"Add LICENSE\" # root commit\n> $ # git add ... git commit cycle\n\nRamkumar, in git 1.7.2 you can simply use \"git checkout --orphan newbranch\".\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"146496","messageId":"20100727172811.GE5351@kytes","threadId":"24538","inReplyTo":"m339v4luk2.fsf@localhost.localdomain","subject":"Re: Recommended work flow with git to send in patches","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2010-07-27T17:28:13Z","receivedAt":"2010-07-27T17:28:13Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Jakub,\n\nJakub Narebski writes:\n> Ramkumar Ramachandra writes:\n> > $ git symbolic-ref HEAD refs/heads/rollout\n> > $ rm .git/index # Git recreates it automatically anyway\n> > $ git add LICENSE\n> > $ git commit -m \"Add LICENSE\" # root commit\n> > $ # git add ... git commit cycle\n> \n> Ramkumar, in git 1.7.2 you can simply use \"git checkout --orphan newbranch\".\n\nThanks for pointing this out! I'm still using many plubming tools- I\nought to find out their equivalents in the new porcelain.\n\n-- Ram\n"},{"id":"146497","messageId":"m3y6cwkew7.fsf@localhost.localdomain","threadId":"24538","inReplyTo":"AANLkTiksAOpFG3vGVGcbeZ0NcpQ5FbDjnZ7yDxUsAY_r@mail.gmail.com","subject":"Re: Recommended work flow with git to send in patches","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-07-27T17:35:06Z","receivedAt":"2010-07-27T17:35:06Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Tong Sun writes:\n\n> Just trying to put all jigsaw puzzle together here. Please correct me\n> if I'm wrong.\n> \n> First of all, philosophy for version control with git:\n> \n> . While developing, small/independent commits are good thing, so that\n> it's easy to decouple different changes.\n> \n> . But when integrating something in a main branch, commits should contain all\n> logical/related changes.\n\nI think that in final results, i.e. in patches that you send, or\ncommits that you send pull request for, you should have commits that\ndo one thing, and do it completely and without breaking. Nevertheless\nhaving small commits that you publish / send to maintainer is a good\nthing; it is always easy to review a few small patches, than one\nmage-patch.\n\n> \n> Steps (using grml-debootstrap as an example):\n> \n> - do initial git pull into grml-debootstrap\n> \n>   git pull git://git.grml.org/grml-debootstrap master\n\nWhy not git-clone (possibly shallow, if you are working on one-shot\npatch or patch series)?\n\nIf you plan to continue working on this repository, and it is not\none-shot patch or patch series, it would be better (easier in the\nfuture) to use \"git remote add\".\n\n> \n> - Go into grml-debootstrap and start a new branch\n> \n>   git checkout -b t/my-working-branch\n> \n> - work on the code, commit, hack, commit, hack, commit -- commit often\n> & commit small\n\nYou can always use 'git commit' + 'git commit --amend' if you want to\nfix previous commit, instead of creating new commit.\n\n> \n> - when AOK and need to integrate patches into main branch, squash all\n> patches into one\n> \n>   git rebase -i origin/master\n\nReorder, edit, squash patches.\n\n> \n> - send in patches via email (to grml-devel@ml.grml.org)\n> \n>   git format-patch origin\n\nWith larger patch series, it could possibly be of the form:\n\n mkdir patches/\n git format-patch -o patches/ --cover-letter\n [edit cover letter, filling in template]\n [edit patches if necessary, adding comments between \"---\" and diffstat]\n\n>   git send-email --to grml-devel@ml.grml.org ...\n> \n> Please correct me if anything above is wrong.\n\nYou can also use some patch management interface, like StGit, Guilt or\nTopGit. I personally use StGit, so the above description is modified\nin that there is 'stg init', there is 'stg new some-patch' and possibly\nmultiple 'stg refresh' when working on commit, there might be 'stg goto's\nand 'stg push'es and 'stg pop's to go back and forth between patches,\nand fix them.\n\nIt's a matter of taste whether to use some kind of patch management /\n/ mail queue interface, or to use interactive rebase instead.\n\n> Now, question, having done above, if I start to work some logically\n> unrelated patches, what steps should I take? (I don't want 'git\n> rebase' to pick up patches that I've already sent in).\n\nIf you want to start to work on some logically unrelated patches, you\nshould start a new branch for that.\n\nAlternatively, when some or all patches are accepted upstream, you\ndownload new changes using 'git pull' or 'git fetch' or 'git remote\nupdate', and then rebase your branch on top of branch it is based on,\nor to be more exact on top of branch your patches are now in. 'git\nrebase' (or 'git pull --rebase' or even 'git pull', if configured\nappropriately) would automatically skip patches that got applied\n(sometimes you need to tell git to 'git rebase --skip' if it didn't\ndetect this).\n\nIt would be 'stg rebase ' (usually is\n'origin'='origin/master' or 'master'), and 'stg clean -a' to remove\nempty applied patches.\n\n\nP.S. Doesn't GRML have web page / wiki page for developers?\n http://grml.org/git/\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"146513","messageId":"AANLkTi=psuiq-GP9zV=pY6swNAUF-MwJt6COrNDVDLqu@mail.gmail.com","threadId":"24538","inReplyTo":"m3y6cwkew7.fsf@localhost.localdomain","subject":"Re: Recommended work flow with git to send in patches","fromName":"Tong Sun","fromEmail":"suntong@cpan.org","sentAt":"2010-07-27T19:48:37Z","receivedAt":"2010-07-27T19:48:37Z","isPatch":false,"sender":{"key":"suntong@cpan.org","avatar":null},"body":"On Tue, Jul 27, 2010 at 1:35 PM, Jakub Narebski wrote:\n\n> Doesn't GRML have web page / wiki page for developers?\n\nYes, http://grml.org/git/, but it is kind of reference book style,\ndoesn't cover much on the work flow, especially on the topic of\nno-writing-privilege user contributing back.\n\n>> - do initial git pull into grml-debootstrap\n>>\n>> git pull git://git.grml.org/grml-debootstrap master\n>\n> Why not git-clone (possibly shallow, if you are working on one-shot\n> patch or patch series)?\n\nOk, to explain it, I have to touch upon my \"life long story\" of using\ngit. Long story short on this, the recommended work flow that I\nsearched and found from the Inet was to do 'git clone' from web then\n'git clone' a local working copy. Here is my trying log:\n\n# Download the latest version of the repository without downloading all the\nhistory, using \"shallow checkouts\".\n\n git clone --depth 1 git://git.grml.org/grml-debootstrap.git\n\ncreate working repo:\n\n $ git-clone --depth 1 grml-debootstrap grml-debootstrap.working\n Initialized empty Git repository in\n/export/repositories/gitwork/grml/grml-debootstrap.working/.git/\n fatal: attempt to fetch/clone from a shallow repository\n ^^^^^^^^^^^^^^^\n\nSeeing that fatal error, and not knowing where to get help from, I\njust gave up the 'git clone' approach. Please be specific (with git\ncommands), how would I use 'git clone' for working on one-shot patch\nor patch series.\n\nGot to run, will comment on the rest later.\n\nthanks\n"},{"id":"146638","messageId":"201007281849.47989.jnareb@gmail.com","threadId":"24538","inReplyTo":"AANLkTi=psuiq-GP9zV=pY6swNAUF-MwJt6COrNDVDLqu@mail.gmail.com","subject":"Re: Recommended work flow with git to send in patches","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-07-28T16:49:45Z","receivedAt":"2010-07-28T16:49:45Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Tue, Jul 27, 2010, Tong Sun wrote:\n> On Tue, Jul 27, 2010 at 1:35 PM, Jakub Narebski wrote:\n> \n> > Doesn't GRML have web page / wiki page for developers?\n> \n> Yes, http://grml.org/git/, but it is kind of reference book style,\n> doesn't cover much on the work flow, especially on the topic of\n> no-writing-privilege user contributing back.\n\nYou could point lack of information for \"leaf\" contributors to them...\n\n> > > - do initial git pull into grml-debootstrap\n> > >\n> > > git pull git://git.grml.org/grml-debootstrap master\n> >\n> > Why not git-clone (possibly shallow, if you are working on one-shot\n> > patch or patch series)?\n> \n> Ok, to explain it, I have to touch upon my \"life long story\" of using\n> git. Long story short on this, the recommended work flow that I\n> searched and found from the Inet was to do 'git clone' from web then\n> 'git clone' a local working copy. Here is my trying log:\n> \n> # Download the latest version of the repository without downloading all the\n> history, using \"shallow checkouts\".\n> \n> git clone --depth 1 git://git.grml.org/grml-debootstrap.git\n\nO.K.\n \n> create working repo:\n> \n> $ git-clone --depth 1 grml-debootstrap grml-debootstrap.working\n> Initialized empty Git repository in\n> /export/repositories/gitwork/grml/grml-debootstrap.working/.git/\n> fatal: attempt to fetch/clone from a shallow repository\n> ^^^^^^^^^^^^^^^\n> \n> Seeing that fatal error, and not knowing where to get help from, I\n> just gave up the 'git clone' approach. Please be specific (with git\n> commands), how would I use 'git clone' for working on one-shot patch\n> or patch series.\n\nI don't understand this second step. Why do you want this second clone?\nIt is totally unnecessary. The clone you make is working repository\nyou can make your contributions in.\n\nIn short, the workflow should look like this (I use here grml as example,\nbut in practice I used git repository as I know it is fairly small, so\nthe numbers, SHA-1 identifiers and branches won't match)\n\n $ cd \n $ git clone --depth 1 git://git.grml.org/grml-debootstrap.git\n Initialized empty Git repository in /grml-debootstrap/.git/\n [...]\n $ cd grml-debootstrap\n $ git branch -a\n * master\n remotes/origin/HEAD -> origin/master\n remotes/origin/master\n [...]\n\nNow you have two choices: you can work on 'master' branch (reasonable\nif you want to do only single thing), or you can create your own branch\n(one branch for one independent unrelated feature). Let's create new\nbranch off 'origin' == 'origin/master' == 'remotes/origin/master'\n\n $ git checkout -b t/my-working-branch origin\n Branch t/my-working-branch set up to track remote branch master from origin.\n Switched to a new branch 't/my-working-branch'\n\nWe could first setup git in such way, that it sets up to track upstream\nvia rebasing rather than via merge (using `branch.autosetuprebase` config\nvariable), but let's not complicate matters.\n\nNow you work on branch\n\n [edit, edit, edit]\n [commit or commit --amend]\n [repeat as necessary]\n \nNow, after some time you feel that your changes are ready for sending.\nFirst, download any new changes, if any.\n\n $ git fetch\n\nThen use interactive rebase to both update your changes to apply to most\nrecent upstream code, and also reorder and edit your patches (e.g. fix\ntypo in commit message, move fix commit and squash it with fixed commit,\netc.)\n\n $ git rebase --interactive origin\n [...]\n Successfully rebased and updated refs/heads/t/my-working-branch.\n\nThen you need to generate patches. If its more of them, I found it good\nidea to save them in separate subdirectory, but it might be not necessary\nfor you\n\n $ git format-patch --cover-letter origin..\n\nThere are some situations where you don't need cover letter, e.g. if you\nare sending single patch, but they are quite useful especially with longer\nseries.\n\n [edit '0000-cover-letter.patch' at least]\n [add comments to individual patches, if necessary]\n\nThen you can either use your email client, or just\n\n $ git send-email --dry-run *.patch\n\n(Here you see why saving patch series to separate subdirectory by\nusing '-o' option makes it easy to pick up relevant patches... ;-))\n\nHTH\n-- \nJakub Narebski\nPoland\n"},{"id":"146661","messageId":"AANLkTikkXQNiaagPGN5cYCDg6hfvojpLcEePWF6UbUDV@mail.gmail.com","threadId":"24538","inReplyTo":"m3y6cwkew7.fsf@localhost.localdomain","subject":"Re: Recommended work flow with git to send in patches","fromName":"Tong Sun","fromEmail":"suntong@cpan.org","sentAt":"2010-07-28T22:40:06Z","receivedAt":"2010-07-28T22:40:06Z","isPatch":false,"sender":{"key":"suntong@cpan.org","avatar":null},"body":"On Tue, Jul 27, 2010 at 1:35 PM, Jakub Narebski wrote:\n\n>> First of all, philosophy for version control with git:\n>>\n>> . While developing, small/independent commits are good thing, so that\n>>   it's easy to decouple different changes.\n>>\n>> . But when integrating something in a main branch, commits should contain all\n>>   logical/related changes.\n>\n> I think that in final results, i.e. in patches that you send, or\n> commits that you send pull request for, you should have commits that\n> do one thing, and do it completely and without breaking.  Nevertheless\n> having small commits that you publish / send to maintainer is a good\n> thing; it is always easy to review a few small patches, than one\n> mage-patch.\n\nYeah, that's actually exactly what I believed before getting feedbacks\nfrom grml developers for squashed patches. It's an interesting topic\nto me, so let's dig deeper into it.\n\nSay that I need to add a feature to a CLI program. I would\ninstinctively divide it into 3 logical steps/patches, 1st to the user\ninterface (the command line handling), 2nd to the implementation, and\n3rd to the document.\n\nDo you think 3 small patches is the way to go, or a single patch is,\nsince all 3 are logically related?\n\nNow back to our topic, thanks for your work flow explanation, I'll\nanswer/ask in this single message.\n\n> Why not git-clone (possibly shallow, if you are working on one-shot\n> patch or patch series)?\n>> Ok, to explain it, I have to touch upon my \"life long story\" of using\n>> git.\n\n> I don't understand this second step. Why do you want this second clone?\n\nThat's what I searched and found from the Inet when I was looking for\nthe recommended work flow, which was to do 'git clone' from web once\nthen 'git clone' several local working copies to work on several\nindependent unrelated features. Now I know creating my own local\nbranches is the way to go.\n\n> If you plan to continue working on this repository, and it is not\n> one-shot patch or patch series, it would be better (easier in the\n> future) to use \"git remote add\".\n\nCould you elaborate more on this with git commands please, so that I\ncan have a full picture?\n\nThanks again for your clearly explanations, I think I don't any\nfurther questions for the moment.\n\ncheers,\n"},{"id":"146664","messageId":"201007290120.05093.jnareb@gmail.com","threadId":"24538","inReplyTo":"AANLkTikkXQNiaagPGN5cYCDg6hfvojpLcEePWF6UbUDV@mail.gmail.com","subject":"Re: Recommended work flow with git to send in patches","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-07-28T23:20:03Z","receivedAt":"2010-07-28T23:20:03Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Thu, Jul 29, 2010, Tong Sun wrote:\n> On Tue, Jul 27, 2010 at 1:35 PM, Jakub Narebski wrote:\n> \n>>> First of all, philosophy for version control with git:\n>>>\n>>> . While developing, small/independent commits are good thing, so that\n>>>   it's easy to decouple different changes.\n>>>\n>>> . But when integrating something in a main branch, commits should contain all\n>>>   logical/related changes.\n>>\n>> I think that in final results, i.e. in patches that you send, or\n>> commits that you send pull request for, you should have commits that\n>> do one thing, and do it completely and without breaking.  Nevertheless\n>> having small commits that you publish / send to maintainer is a good\n>> thing; it is always easy to review a few small patches, than one\n>> mage-patch.\n> \n> Yeah, that's actually exactly what I believed before getting feedbacks\n> from grml developers for squashed patches. It's an interesting topic\n> to me, so let's dig deeper into it.\n> \n> Say that I need to add a feature to a CLI program. I would\n> instinctively divide it into 3 logical steps/patches, 1st to the user\n> interface (the command line handling), 2nd to the implementation, and\n> 3rd to the document.\n> \n> Do you think 3 small patches is the way to go, or a single patch is,\n> since all 3 are logically related?\n\nIn this situation it is obvious to me that you should send single\nsquashed patch, as otherwise commit does not contain all related and\nconnected changes: command line handling without implementation doesn't\nmake sense, and if you are implementing something, you should document\nit.\n\n\nAn example of change that might, or might be not split into two commits\nis simple bug fix. You can either first write failing test showing the\nbreakage, and then write fix and change test expectation to pass, or you\ncan write fix and test in one commit.\n\nHere are a few generalized examples from git repository history where\nyou might want to send a change as a series of patches rather than in\none large single patch:\n\n1. If you are improving documentation, you can split your patch into\n one adding missing documentation for some feature, and second adding\n examples of using said feature.\n\n2. If you plan to make some part of code used more widely, you can in\n first commit make API public, in second add support for feature to\n wider codebase, and in third add tests for this support.\n\n Similar thing with having doing refactoring first, then using this\n refactoring to easy add new feature.\n\n3. If you are fixing some compiler warnings, fixing each class/type\n of warnings could be made into separate commits.\n\n4. You can have one commit adding feature, and second adding support\n for said feature (for parameters / subcommands that use said feature)\n to shell completion.\n\nEtc.\n\n> Now back to our topic, thanks for your work flow explanation, I'll\n> answer/ask in this single message.\n> \n>> Why not git-clone (possibly shallow, if you are working on one-shot\n>> patch or patch series)?\n>>>\n>>> Ok, to explain it, I have to touch upon my \"life long story\" of using\n>>> git.\n> \n>> I don't understand this second step. Why do you want this second clone?\n> \n> That's what I searched and found from the Inet when I was looking for\n> the recommended work flow, which was to do 'git clone' from web once\n> then 'git clone' several local working copies to work on several\n> independent unrelated features. Now I know creating my own local\n> branches is the way to go.\n\nI think \"fork (clone) to branch\" was from some very ancient git tutorials\n(git has in-place branching and branch switching from time immemorial),\nor from some (outdated?) Mercurial documentation.\n\nThat said shallow clone should be improved, so you can clone from\nshallow clone with the same depth or shallower. Current implementation\nis a bit lacking.\n\n>> If you plan to continue working on this repository, and it is not\n>> one-shot patch or patch series, it would be better (easier in the\n>> future) to use \"git remote add\".\n> \n> Could you elaborate more on this with git commands please, so that I\n> can have a full picture?\n> \n> Thanks again for your clearly explanations, I think I don't any\n> further questions for the moment.\n\nI don't think that would apply in your situation, but \"git remote add\"\nis used if you want to fetch changes from more than one upstream repository\n(or you want to configure repository to push into). This is an alternative\nto one-shot \"git pull \" which does not save _any_ information\nabout upstream you fetched (pulled) from.\n\nSee git-remote manpage for details.\n-- \nJakub Narebski\nPoland\n"},{"id":"146665","messageId":"AANLkTinfobkVFVfqgUV9QiExosfW=W3gAFr3DmDb1URw@mail.gmail.com","threadId":"24538","inReplyTo":"201007290120.05093.jnareb@gmail.com","subject":"Re: Recommended work flow with git to send in patches","fromName":"Tong Sun","fromEmail":"suntong@cpan.org","sentAt":"2010-07-28T23:30:33Z","receivedAt":"2010-07-28T23:30:33Z","isPatch":false,"sender":{"key":"suntong@cpan.org","avatar":null},"body":"On Wed, Jul 28, 2010 at 7:20 PM, Jakub Narebski wrote:\n>>> If you plan to continue working on this repository, and it is not\n>>> one-shot patch or patch series, it would be better (easier in the\n>>> future) to use \"git remote add\".\n>>\n> . . .\n> I don't think that would apply in your situation, but \"git remote add\"\n> is used if you want to fetch changes from more than one upstream repository\n> (or you want to configure repository to push into).  This is an alternative\n> to one-shot \"git pull \" which does not save _any_ information\n> about upstream you fetched (pulled) from.\n\nGot it.\n\n> See git-remote manpage for details.\n\nand http://www.kernel.org/pub/software/scm/git/docs/gittutorial.html as well.\n\nthanks again. no more questions for now.\n\ncheers\n"}]}