{"thread":{"id":"43321","subject":"Re: Patch to tutorial.txt","startedAt":"2006-11-19T22:44:50Z","lastAt":"2006-11-20T20:11:22Z","messageCount":8,"participants":["Petr Baudis","Paolo Ciarrocchi","Alan Chandler","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"295246","messageId":"4d8e3fd30611191444r710f23e5uc488d35aa4abaf06@mail.gmail.com","threadId":"43321","inReplyTo":null,"subject":"Patch to tutorial.txt","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2006-11-19T22:44:50Z","receivedAt":"2006-11-19T22:44:50Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"Hi all,\nI'm reading the tutorial and trying to improve it while studying git.\n\nFirst attempt here:\nFrom 0b98769dfe16e3ba8cde698b75cb1067658c38e7 Mon Sep 17 00:00:00 2001\nFrom: Paolo Ciarrocchi \nDate: Sun, 19 Nov 2006 23:41:31 +0100\nSubject: [PATCH] One of the comment was not really clear, rephrased to\nmake it easier to be understood by the reader\n\n\nSigned-off-by: Paolo Ciarrocchi \n---\n Documentation/tutorial.txt | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/tutorial.txt b/Documentation/tutorial.txt\nindex 554ee0a..6edfb5a 100644\n--- a/Documentation/tutorial.txt\n+++ b/Documentation/tutorial.txt\n@@ -141,7 +141,7 @@ $ git commit -a\n ------------------------------------------------\n\n at this point the two branches have diverged, with different changes\n-made in each. To merge the changes made in the two branches, run\n+made in each. To merge the changes made in experimental into master run\n\n ------------------------------------------------\n $ git pull . experimental\n-- \n1.4.4.ge3d4\n\n\nRegards,\n-- \nPaolo\nhttp://docs.google.com/View?docid=dhbdhs7d_4hsxqc8\nhttp://www.linkedin.com/pub/0/132/9a3\nNon credo nelle otto del mattino. Però esistono. Le otto del mattino\nsono l'incontrovertibile prova della presenza del male nel mondo.\n"},{"id":"297252","messageId":"ejqnh8$peb$1@sea.gmane.org","threadId":"43321","inReplyTo":"4d8e3fd30611191444r710f23e5uc488d35aa4abaf06@mail.gmail.com","subject":"Re: Patch to tutorial.txt","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-19T22:59:13Z","receivedAt":"2006-11-19T22:59:13Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Paolo Ciarrocchi wrote:\n\n> From 0b98769dfe16e3ba8cde698b75cb1067658c38e7 Mon Sep 17 00:00:00 2001\n\nI think you should remove this line.\n\n> From: Paolo Ciarrocchi \n> Date: Sun, 19 Nov 2006 23:41:31 +0100\n> Subject: [PATCH] One of the comment was not really clear, rephrased to\n> make it easier to be understood by the reader\n\nWordwrap. Perhaps it would be better to split description into short line,\nand two-line description.\n\n[...]\n> ------------------------------------------------\n> \n> at this point the two branches have diverged, with different changes\n> -made in each. To merge the changes made in the two branches, run\n> +made in each. To merge the changes made in experimental into master run\n\nI would rather say:\n To merge the changes made in the two branches into master, run\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"296807","messageId":"200611200949.32722.jnareb@gmail.com","threadId":"43321","inReplyTo":"4d8e3fd30611200030p1d117445qd3f7d619c18a0633@mail.gmail.com","subject":"Re: Patch to tutorial.txt","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-20T08:49:31Z","receivedAt":"2006-11-20T08:49:31Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 20 Nov 2006, Paolo Ciarrocchi wrote:\n> On 11/19/06, Jakub Narebski wrote:\n>> Paolo Ciarrocchi wrote:\n\n>>> From: Paolo Ciarrocchi \n>>> Date: Sun, 19 Nov 2006 23:41:31 +0100\n>>> Subject: [PATCH] One of the comment was not really clear, rephrased to\n>>> make it easier to be understood by the reader\n>>\n>> Wordwrap. Perhaps it would be better to split description into short line,\n>> and two-line description.\n\nSee http://git.or.cz/gitwiki/CommitMessageConventions\n\nIn short, it is better to split description into short one-line\ndescription, for example\n \"Documentation: Make comment about merging in tutorial.txt more clear\"\nfollowed by empty line, then longer description of changes (if any), for\nexample\n\n One of the comment was not really clear, rephrased to make it easier\n to be understood by the reader\n\nfollowed by empty line, then signoff line, for example\n\n Signed-off-by: Paolo Ciarrocchi \n\n> This is not clear to me, when I do a \"git commit -a\" I can add a text using vi,\n> should I manually split the text in multiple lines?\n> Only the first line will be part of the Subject?\n\nYes. The rest will be in the email body.\n \n>> [...]\n>>> ------------------------------------------------\n>>>\n>>> at this point the two branches have diverged, with different changes\n>>> -made in each. To merge the changes made in the two branches, run\n>>> +made in each. To merge the changes made in experimental into master run\n>>\n>> I would rather say:\n>> To merge the changes made in the two branches into master, run\n> \n> Why Jakub? There are only two branches, master and experimental.\n> While sitting in master and doing git pull . experimental I would\n> expect to merge I did in experimental into master. Changes did in\n> master are alreay merged in master. Am I wrong?\n\nFor me, \"merge\" in \"to merge the changes\" phrase is merge in common-sense\nmeaning of the world, not the SCM jargon. Merge the changes == join the\nchanges, so you have to give both sides, both changes you join.\n\nMerge the changes == take changes in branch 'experimental' since forking,\ntake changes in branch 'master' since forking, join those changes\ntogether (merge), and put the result of this joining (this merge) into\nbranch 'master'.\n\nOn the contrary, in \"merge branch 'experimenta' into 'master'\" phrase\n\"merge\" is in the SCM meaning of this word.\n\n\nJust my 2 eurocoents of not native English speaker...\n-- \nJakub Narebski\n"},{"id":"297520","messageId":"4d8e3fd30611200110y224b5b8dpf974d30d738455c9@mail.gmail.com","threadId":"43321","inReplyTo":"200611200949.32722.jnareb@gmail.com","subject":"Re: Patch to tutorial.txt","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2006-11-20T09:10:36Z","receivedAt":"2006-11-20T09:10:36Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On 11/20/06, Jakub Narebski wrote:\n> On Mon, 20 Nov 2006, Paolo Ciarrocchi wrote:\n> > On 11/19/06, Jakub Narebski wrote:\n> >> Paolo Ciarrocchi wrote:\n>\n> >>> From: Paolo Ciarrocchi \n> >>> Date: Sun, 19 Nov 2006 23:41:31 +0100\n> >>> Subject: [PATCH] One of the comment was not really clear, rephrased to\n> >>> make it easier to be understood by the reader\n> >>\n> >> Wordwrap. Perhaps it would be better to split description into short line,\n> >> and two-line description.\n>\n> See http://git.or.cz/gitwiki/CommitMessageConventions\n\nThanks! I was not aware of that.\n\n> In short, it is better to split description into short one-line\n> description, for example\n> \"Documentation: Make comment about merging in tutorial.txt more clear\"\n> followed by empty line, then longer description of changes (if any), for\n> example\n>\n> One of the comment was not really clear, rephrased to make it easier\n> to be understood by the reader\n>\n> followed by empty line, then signoff line, for example\n>\n> Signed-off-by: Paolo Ciarrocchi \n\nOk, but the Signed/off-by part should handled by the -s option in\ngit-format-patch.\n\n> > This is not clear to me, when I do a \"git commit -a\" I can add a text using vi,\n> > should I manually split the text in multiple lines?\n> > Only the first line will be part of the Subject?\n>\n> Yes. The rest will be in the email body.\n>\n> >> [...]\n> >>> ------------------------------------------------\n> >>>\n> >>> at this point the two branches have diverged, with different changes\n> >>> -made in each. To merge the changes made in the two branches, run\n> >>> +made in each. To merge the changes made in experimental into master run\n> >>\n> >> I would rather say:\n> >> To merge the changes made in the two branches into master, run\n> >\n> > Why Jakub? There are only two branches, master and experimental.\n> > While sitting in master and doing git pull . experimental I would\n> > expect to merge I did in experimental into master. Changes did in\n> > master are alreay merged in master. Am I wrong?\n>\n> For me, \"merge\" in \"to merge the changes\" phrase is merge in common-sense\n> meaning of the world, not the SCM jargon. Merge the changes == join the\n> changes, so you have to give both sides, both changes you join.\n>\n> Merge the changes == take changes in branch 'experimental' since forking,\n> take changes in branch 'master' since forking, join those changes\n> together (merge), and put the result of this joining (this merge) into\n> branch 'master'.\n>\n> On the contrary, in \"merge branch 'experimenta' into 'master'\" phrase\n> \"merge\" is in the SCM meaning of this word.\n>\n>\n> Just my 2 eurocoents of not native English speaker...\n\nI'm not a native English speaker as well, furthemore I'm still not\nconfident with git so your comments are more then appreciated!\n\nCiao,\n-- \nPaolo\nhttp://docs.google.com/View?docid=dhbdhs7d_4hsxqc8\nhttp://www.linkedin.com/pub/0/132/9a3\nNon credo nelle otto del mattino. Però esistono. Le otto del mattino\nsono l'incontrovertibile prova della presenza del male nel mondo.\n"},{"id":"296337","messageId":"200611201025.11048.jnareb@gmail.com","threadId":"43321","inReplyTo":"4d8e3fd30611200110y224b5b8dpf974d30d738455c9@mail.gmail.com","subject":"Re: Patch to tutorial.txt","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-20T09:25:10Z","receivedAt":"2006-11-20T09:25:10Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Paolo Ciarrocchi wrote:\n> On 11/20/06, Jakub Narebski wrote:\n>\n>> followed by empty line, then signoff line, for example\n>>\n>> Signed-off-by: Paolo Ciarrocchi \n> \n> Ok, but the Signed/off-by part should handled by the -s option in\n> git-format-patch.\n\nSigned-off-by _can_ be added by -s option in git-format-patch, but \nI think it is usually better to have it added in the commit, by the -s \noption to git-commit.\n\n-- \nJakub Narebski\n"},{"id":"297099","messageId":"4d8e3fd30611200134u33ee3a83mfce7c4da89d630d4@mail.gmail.com","threadId":"43321","inReplyTo":"200611201025.11048.jnareb@gmail.com","subject":"Re: Patch to tutorial.txt","fromName":"Paolo Ciarrocchi","fromEmail":"paolo.ciarrocchi@gmail.com","sentAt":"2006-11-20T09:34:42Z","receivedAt":"2006-11-20T09:34:42Z","isPatch":false,"sender":{"key":"paolo.ciarrocchi@gmail.com","avatar":null},"body":"On 11/20/06, Jakub Narebski wrote:\n> Paolo Ciarrocchi wrote:\n> > On 11/20/06, Jakub Narebski wrote:\n> >\n> >> followed by empty line, then signoff line, for example\n> >>\n> >> Signed-off-by: Paolo Ciarrocchi \n> >\n> > Ok, but the Signed/off-by part should handled by the -s option in\n> > git-format-patch.\n>\n> Signed-off-by _can_ be added by -s option in git-format-patch, but\n> I think it is usually better to have it added in the commit, by the -s\n> option to git-commit.\n\nOh, I wan not aware of that as well. Maybe it's worth to be mentioned\nin the tutorial.\n\nI'll properly redo the patch later today or tomorrow.\n\nThanks!\nCiao,\n-- \nPaolo\nhttp://docs.google.com/View?docid=dhbdhs7d_4hsxqc8\nhttp://www.linkedin.com/pub/0/132/9a3\nNon credo nelle otto del mattino. Però esistono. Le otto del mattino\nsono l'incontrovertibile prova della presenza del male nel mondo.\n"},{"id":"294356","messageId":"20061120131321.GA7201@pasky.or.cz","threadId":"43321","inReplyTo":"200611200949.32722.jnareb@gmail.com","subject":"Re: Patch to tutorial.txt","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-20T13:13:21Z","receivedAt":"2006-11-20T13:13:21Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Mon, Nov 20, 2006 at 09:49:31AM CET, Jakub Narebski wrote:\n> On Mon, 20 Nov 2006, Paolo Ciarrocchi wrote:\n> > On 11/19/06, Jakub Narebski wrote:\n> >> Paolo Ciarrocchi wrote:\n> >> [...]\n> >>> ------------------------------------------------\n> >>>\n> >>> at this point the two branches have diverged, with different changes\n> >>> -made in each. To merge the changes made in the two branches, run\n> >>> +made in each. To merge the changes made in experimental into master run\n> >>\n> >> I would rather say:\n> >> To merge the changes made in the two branches into master, run\n> > \n> > Why Jakub? There are only two branches, master and experimental.\n> > While sitting in master and doing git pull . experimental I would\n> > expect to merge I did in experimental into master. Changes did in\n> > master are alreay merged in master. Am I wrong?\n> \n> For me, \"merge\" in \"to merge the changes\" phrase is merge in common-sense\n> meaning of the world, not the SCM jargon. Merge the changes == join the\n> changes, so you have to give both sides, both changes you join.\n> \n> Merge the changes == take changes in branch 'experimental' since forking,\n> take changes in branch 'master' since forking, join those changes\n> together (merge), and put the result of this joining (this merge) into\n> branch 'master'.\n> \n> On the contrary, in \"merge branch 'experimenta' into 'master'\" phrase\n> \"merge\" is in the SCM meaning of this word.\n\nI personally find the SVM meaning much less confusing, but I can't tell\nhow much I've been contaminated already - \"merge in the two branches\ninto master\" really strongly suggests to me that it's about some _other_\ntwo branches.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\nThe meaning of Stonehenge in Traflamadorian, when viewed from above, is:\n\"Replacement part being rushed with all possible speed.\"\n"},{"id":"295360","messageId":"200611202011.22787.alan@chandlerfamily.org.uk","threadId":"43321","inReplyTo":"200611200949.32722.jnareb@gmail.com","subject":"Re: Patch to tutorial.txt","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2006-11-20T20:11:22Z","receivedAt":"2006-11-20T20:11:22Z","isPatch":false,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Monday 20 November 2006 08:49, Jakub Narebski wrote:\n> On Mon, 20 Nov 2006, Paolo Ciarrocchi wrote:\n> >>> -made in each. To merge the changes made in the two branches, run\n> >>> +made in each. To merge the changes made in experimental into master\n\n> >> I would rather say:\n> >> To merge the changes made in the two branches into master, run\n> >\n> > Why Jakub? There are only two branches, master and experimental.\n> > While sitting in master and doing git pull . experimental I would\n> > expect to merge I did in experimental into master. Changes did in\n> > master are alreay merged in master. Am I wrong?\n>\n> For me, \"merge\" in \"to merge the changes\" phrase is merge in common-sense\n> meaning of the world, not the SCM jargon. Merge the changes == join the\n> changes, so you have to give both sides, both changes you join.\n>\n> Merge the changes == take changes in branch 'experimental' since forking,\n> take changes in branch 'master' since forking, join those changes\n> together (merge), and put the result of this joining (this merge) into\n> branch 'master'.\n>\n> On the contrary, in \"merge branch 'experimenta' into 'master'\" phrase\n> \"merge\" is in the SCM meaning of this word.\n>\n>\n> Just my 2 eurocoents of not native English speaker...\n\nAs a native English speaker the way the tutorial was before any of these \nchanges meant that the contents of experimental and master had merged into \none, but there was not specific indication of where this merged result had \nbeen put \n\nFrom _your_ phrasing I took the meaning that there were two independent \nbranches which then got merged into master although that leaves me puzzled \nbecause there is only one other independant branch and thats the experimental \none \n\nI think the wording Paolo used is clearer and precisely right - we are merging \nthe experimental stuff into master and experimental remains as it was \n(although in a fast forward experimental and master end up the same - this is \nnot true in the example in the tutorial which says that changes are made on \nboth branches).\n\n\n\n-- \nAlan Chandler\n"}]}