{"thread":{"id":"13285","subject":"[PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","startedAt":"2008-04-27T15:16:10Z","lastAt":"2008-05-16T14:22:55Z","messageCount":23,"participants":["Brian Gernhardt","Johannes Schindelin","Junio C Hamano","Jeff King","Mike Ralphson","Jörg Sommer"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"75295","messageId":"20080427151610.GB57955@Hermes.local","threadId":"13285","inReplyTo":null,"subject":"[PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2008-04-27T15:16:10Z","receivedAt":"2008-04-27T15:16:10Z","isPatch":true,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"t3404-rebase-interactive used `grep -Fx 0` to match against `wc -l`\noutput. This fails on OS X and any other system where wc outputs\nwhitespace. Use `test 0 = `... instead, like we do in other tests.\n\nSigned-off-by: Brian Gernhardt \n---\n\n Should this construct go into CodingStyle? I seem to have to write\n patches like this every month or so.\n\n t/t3404-rebase-interactive.sh | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh\nindex d20ed4f..f204284 100755\n--- a/t/t3404-rebase-interactive.sh\n+++ b/t/t3404-rebase-interactive.sh\n@@ -211,7 +211,7 @@ test_expect_success 'setting marks works' '\n \ttest \"$(git rev-parse HEAD~2)\" = \\\n \t\t\"$(git rev-parse refs/rebase-marks/42)\" &&\n \tgit rebase --abort &&\n-\tls $marks_dir | wc -l | grep -Fx 0\n+\ttest 0 = $(ls $marks_dir | wc -l)\n '\n \n test_expect_success 'reset with nonexistent mark fails' '\n-- \n1.5.5.1.174.g8f57349\n"},{"id":"75296","messageId":"alpine.DEB.1.00.0804271620440.16320@eeepc-johanness","threadId":"13285","inReplyTo":"20080427151610.GB57955@Hermes.local","subject":"Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-27T15:22:29Z","receivedAt":"2008-04-27T15:22:29Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 27 Apr 2008, Brian Gernhardt wrote:\n\n> Should this construct go into CodingStyle? I seem to have to write \n> patches like this every month or so.\n\nYes, probably. I am very sorry, I really should have reviewed those \npatches better (I know that \":\" in expr is better than \"match\", \"tac\" is \nsomething to be avoided, and \"wc -l\" can output whitespace). It did not \nhelp that I hated the fact that that series changed the original design \nwithout even understanding it.\n\nCiao,\nDscho\n"},{"id":"75297","messageId":"B287EA35-6C5D-4A5A-BEF1-C55A70D913ED@silverinsanity.com","threadId":"13285","inReplyTo":"alpine.DEB.1.00.0804271620440.16320@eeepc-johanness","subject":"Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2008-04-27T15:32:24Z","receivedAt":"2008-04-27T15:32:24Z","isPatch":true,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Apr 27, 2008, at 11:22 AM, Johannes Schindelin wrote:\n\n> On Sun, 27 Apr 2008, Brian Gernhardt wrote:\n>\n>> Should this construct go into CodingStyle? I seem to have to write\n>> patches like this every month or so.\n>\n> Yes, probably. I am very sorry, I really should have reviewed those\n> patches better (I know that \":\" in expr is better than \"match\", \n> \"tac\" is\n> something to be avoided, and \"wc -l\" can output whitespace). It did \n> not\n> help that I hated the fact that that series changed the original \n> design\n> without even understanding it.\n\nEh, not everyone's perfect. I would have used `rev` instead of `tac` \nand still been wrong for Solaris. But it seems that the `wc -l` \nwhitespace issue seems to hit nearly everyone at some point, so I \nthought it would be a good candidate for CodingStyle.\n\nPersonally, I'd love to have the time to review all the patches to \ncatch these issues while still on the list instead of waiting until \nthey hit next and I tried to compile it. But I don't always notice, \nhave time, or care myself.\n\n~~ Brian\n"},{"id":"75303","messageId":"7vej8rgq62.fsf@gitster.siamese.dyndns.org","threadId":"13285","inReplyTo":"alpine.DEB.1.00.0804271620440.16320@eeepc-johanness","subject":"Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-27T17:31:49Z","receivedAt":"2008-04-27T17:31:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> ... It did not \n> help that I hated the fact that that series changed the original design \n> without even understanding it.\n\nCare to elaborate on this point further? I do not get it.\n\nDo you mean to say \"I hate it because it does things differently from how\nI did it originally\", or \"Because it does things differently from how the\noriginal did, it breaks this and that cases\"?\n\nIf the latter, \"this and that\" part is especially useful. A solution to\nfix that may end up to be closer to the original implementation.\n"},{"id":"75361","messageId":"20080428094119.GA20499@sigill.intra.peff.net","threadId":"13285","inReplyTo":"B287EA35-6C5D-4A5A-BEF1-C55A70D913ED@silverinsanity.com","subject":"Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-04-28T09:41:19Z","receivedAt":"2008-04-28T09:41:19Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Apr 27, 2008 at 11:32:24AM -0400, Brian Gernhardt wrote:\n\n> Eh, not everyone's perfect. I would have used `rev` instead of `tac` and \n> still been wrong for Solaris. But it seems that the `wc -l` whitespace \n> issue seems to hit nearly everyone at some point, so I thought it would be \n> a good candidate for CodingStyle.\n>\n> Personally, I'd love to have the time to review all the patches to catch \n> these issues while still on the list instead of waiting until they hit \n> next and I tried to compile it. But I don't always notice, have time, or \n> care myself.\n\nBTW, how did you discover this bug? Through normal use, or was there a\nfailing test?\n\nIf a failing test, then I wonder if we could get a few people to set up\nautomated tests on alternate platforms. IIRC, Junio makes sure that\nmaster always passes test on his Linux box and KO (Debian and Redhat, I\nthink?). Other platforms could \"git pull && make test\" daily. I could\nprobably do Solaris (once I get the tests to complete pass at all!) and\nFreeBSD 6.\n\n-Peff\n"},{"id":"75362","messageId":"e2b179460804280256g4ff903bu39c9460086df7157@mail.gmail.com","threadId":"13285","inReplyTo":"20080428094119.GA20499@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Mike Ralphson","fromEmail":"mike.ralphson@gmail.com","sentAt":"2008-04-28T09:56:05Z","receivedAt":"2008-04-28T09:56:05Z","isPatch":true,"sender":{"key":"mike.ralphson@gmail.com","avatar":"https://avatars.githubusercontent.com/u/21603?v=4"},"body":"2008/4/28 Jeff King :\n> If a failing test, then I wonder if we could get a few people to set up\n> automated tests on alternate platforms. IIRC, Junio makes sure that\n> master always passes test on his Linux box and KO (Debian and Redhat, I\n> think?). Other platforms could \"git pull && make test\" daily. I could\n> probably do Solaris (once I get the tests to complete pass at all!) and\n> FreeBSD 6.\n\nI could run automated build / test [/ bisect?] cycles on AIX if of any interest.\n\nMike\n"},{"id":"75363","messageId":"alpine.DEB.1.00.0804281112500.2949@eeepc-johanness","threadId":"13285","inReplyTo":"7vej8rgq62.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-28T10:13:04Z","receivedAt":"2008-04-28T10:13:04Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 27 Apr 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > ... It did not help that I hated the fact that that series changed \n> > the original design without even understanding it.\n> \n> Care to elaborate on this point further? I do not get it.\n\nThe original implementation of -p was modeled closely after filter-branch, \nin that it created a subdirectory (dotest/rewritten) containing the new \ncommit names for those commits that were rewritten.\n\nNow, whenever a commit was picked, the parents would be looked up in \ndotest/rewritten, and replaced with the rewritten name (or left unchanged \nif they were not rewritten).\n\nIn that manner, every commit is identified by the (original) commit name. \nSurprisingly, this is the way Git was meant to operate\n\nNow, a mark command has been introduced which is totally unnecessary. \nCommits can _still_ be identified by their (original) commit name. That's \nthe whole assumption rebase -i relies on.\n\nBasically, the output of rebase -i -p is ugly now, because you have _two_ \nways of specifying things, and frankly, I would have to read documentation \nto find out when to use what. And I maintain that this was not necessary \nwith the old way rebase -i operated.\n\nSo I am really unhappy that this patch series made it in, and I am even \nmore unhappy that my suggestions (which I made, in spite of moving between \ntwo countries, and in spite of spending a lot of time with someone very \nspecial, and therefore having less time for Git than I would have liked \nto) were blatantly ignored.\n\nIt would have been easier for me if I would not be so utterly convinced \nthat the \"new\" way is so much more complicated and unintuitive than what I \nsuggested.\n\nAnd now it is already in \"next\", which does not help me at all (me being \nvery busy at the moment to find a job). I am also slightly uneasy about \nthe fact that a few obvious mistakes had to be fixed in the last days.\n\nFormulations such as \"deliberately leaves $DOTEST directory behind if \nclean-up fails\" make me wonder, too: I sincerely hope that I misunderstand \nthe intention of this message.\n\nI have the feeling that I have to repeat my point again, so that it is not \nignored -- again. Maybe an example would help:\n\n-- snip --\npick abcdefg This is the first commit to be picked\nreset cdefghij\npick zyxwvux A commit in a side-branch\nmerge recursive abcdefg\n-- snap --\n\nI am convinced that this syntax does not need much explanation.\n\nA patch implementing a syntax like this would have won my unilateral \napproval (modulo expr/tac quirks, but that would have been easy to fix).\n\nCiao,\nDscho who does not like complicator's gloves\n"},{"id":"75372","messageId":"slrng1bdsf.25r.joerg@alea.gnuu.de","threadId":"13285","inReplyTo":"alpine.DEB.1.00.0804281112500.2949@eeepc-johanness","subject":"Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Jörg Sommer","fromEmail":"joerg@alea.gnuu.de","sentAt":"2008-04-28T11:40:00Z","receivedAt":"2008-04-28T11:40:00Z","isPatch":true,"sender":{"key":"joerg@alea.gnuu.de","avatar":null},"body":"Hi,\n\nJohannes Schindelin wrote:\n> On Sun, 27 Apr 2008, Junio C Hamano wrote:\n>\n>> Johannes Schindelin writes:\n>> \n>> > ... It did not help that I hated the fact that that series changed \n>> > the original design without even understanding it.\n>> \n>> Care to elaborate on this point further? I do not get it.\n>\n> The original implementation of -p was modeled closely after filter-branch, \n> in that it created a subdirectory (dotest/rewritten) containing the new \n> commit names for those commits that were rewritten.\n\nBut that wasn't the way rebase -i works. You had to jump in before\npick_one does anything which clearly shows you did something different\nfrom the default way.\n\n> Now, whenever a commit was picked, the parents would be looked up in \n> dotest/rewritten, and replaced with the rewritten name (or left unchanged \n> if they were not rewritten).\n\nThis approach doesn't work when you change the order of commits.\nTake the commit A, B and C in this order and reorder them to A C B:\n1. pick A, A^ was not rewritten, nothing changed, A stays the same\n2. pick C, C^ was not rewritten, nothing changed, C stays the same\n3. pick B, B^ was not rewritten, nothing changed, B stays the same\n\nDepending on your handling of the new tip of the branch you loose C or,\nas your code did, nothing changed, because you made the assumption the\nnew HEAD is the rewritten old HEAD.\n\n> Basically, the output of rebase -i -p is ugly now, because you have _two_ \n> ways of specifying things,\n\n> I have the feeling that I have to repeat my point again, so that it is not \n> ignored -- again. Maybe an example would help:\n>\n> -- snip --\n> pick abcdefg This is the first commit to be picked\n> reset cdefghij\n> pick zyxwvux A commit in a side-branch\n> merge recursive abcdefg\n> -- snap --\n>\n> I am convinced that this syntax does not need much explanation.\n\nBut above you said this syntax + mark is “ugly”. Strange.\n\n> A patch implementing a syntax like this would have won my unilateral \n> approval\n\nI doubt this. You refused any changes to your idea and your code from the\nbeginning. You didn't answer questions and doesn't take part on the\ndiscussion [1] about the new syntax.\n\nBye, Jörg.\n\n[1] <7vabkoufzq.fsf@gitster.siamese.dyndns.org>\n-- \nEs gibt nichts schöneres als dem Schweigen eines Dummkopfes zuzuhören.\n \t \t\t \t \t (Helmut Quatlinger)\n"},{"id":"75370","messageId":"8BF98729-6665-489A-A77B-59498B6C8C29@silverinsanity.com","threadId":"13285","inReplyTo":"20080428094119.GA20499@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Brian Gernhardt","fromEmail":"benji@silverinsanity.com","sentAt":"2008-04-28T12:40:27Z","receivedAt":"2008-04-28T12:40:27Z","isPatch":true,"sender":{"key":"benji@silverinsanity.com","avatar":"https://gravatar.com/avatar/e06c101dbc25c68114d859b4a9ec7cf8a2c52fd2b0270ef0eac0e2e63ff22311?d=mp&s=160"},"body":"\nOn Apr 28, 2008, at 5:41 AM, Jeff King wrote:\n> BTW, how did you discover this bug? Through normal use, or was there a\n> failing test?\n\nMy small series of one-line patches were from trying to get t3404 \n(IIRC) to work. So our tests do help. ;-)\n\n> If a failing test, then I wonder if we could get a few people to set \n> up\n> automated tests on alternate platforms. IIRC, Junio makes sure that\n> master always passes test on his Linux box and KO (Debian and \n> Redhat, I\n> think?). Other platforms could \"git pull && make test\" daily. I could\n> probably do Solaris (once I get the tests to complete pass at all!) \n> and\n> FreeBSD 6.\n\nI have a script that boils down to 'make && make test && make \ninstall'. I pull, check changes, and then run it once or twice a \nweek. I can't dedicate my laptop to automated testing, but I do raise \na fuss when it fails.\n\nA build farm would help, especially with simple portability errors \nlike this. Would be good to get OS X, Solaris (our old nemesis), and a \nfew variations for /bin/sh. But I don't really have a good machine to \nvolunteer for the effort myself.\n\n~~ Brian G.\n"},{"id":"75376","messageId":"alpine.DEB.1.00.0804281409030.5399@eeepc-johanness","threadId":"13285","inReplyTo":"slrng1bdsf.25r.joerg@alea.gnuu.de","subject":"Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-28T13:42:01Z","receivedAt":"2008-04-28T13:42:01Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\ndon't cull me from the Cc: list. This has been mentioned on this list so \noften, it is not even funny any more.\n\nOn Mon, 28 Apr 2008, Jörg Sommer wrote:\n\n> Johannes Schindelin wrote:\n> > On Sun, 27 Apr 2008, Junio C Hamano wrote:\n> >\n> >> Johannes Schindelin writes:\n> >> \n> >> > ... It did not help that I hated the fact that that series changed \n> >> > the original design without even understanding it.\n> >> \n> >> Care to elaborate on this point further? I do not get it.\n> >\n> > The original implementation of -p was modeled closely after \n> > filter-branch, in that it created a subdirectory (dotest/rewritten) \n> > containing the new commit names for those commits that were rewritten.\n> \n> But that wasn't the way rebase -i works.\n\nI know exactly how it works. D'oh.\n\n> You had to jump in before pick_one does anything which clearly shows you \n> did something different from the default way.\n\nThat is bullshit. I did not do anything \"different from the default way\". \nI carefully designed an interface that was easy to understand, because it \nmimicked how you would do the same _by hand_, but without the hassle to \nactually having to do everything by hand.\n\nIn other words, rebase -i is just a cherry-pick in a loop.\n\nAnd _exactly_ the same should have been done for -p. Namely, _not_ \nintroduce some artificial marks, but use the _commit names_!\n\n> > Now, whenever a commit was picked, the parents would be looked up in \n> > dotest/rewritten, and replaced with the rewritten name (or left \n> > unchanged if they were not rewritten).\n> \n> This approach doesn't work when you change the order of commits.\n> Take the commit A, B and C in this order and reorder them to A C B:\n> 1. pick A, A^ was not rewritten, nothing changed, A stays the same\n> 2. pick C, C^ was not rewritten, nothing changed, C stays the same\n> 3. pick B, B^ was not rewritten, nothing changed, B stays the same\n\nYou carefully ignored how I intended the parents to be used: only for \nmerges.\n\n> > Basically, the output of rebase -i -p is ugly now, because you have \n> > _two_ ways of specifying things,\n> \n> > I have the feeling that I have to repeat my point again, so that it is not \n> > ignored -- again. Maybe an example would help:\n> >\n> > -- snip --\n> > pick abcdefg This is the first commit to be picked\n> > reset cdefghij\n> > pick zyxwvux A commit in a side-branch\n> > merge recursive abcdefg\n> > -- snap --\n> >\n> > I am convinced that this syntax does not need much explanation.\n> \n> But above you said this syntax + mark is “ugly”. Strange.\n\nYou know, I find it strange how you try to make a _point_ in \nmisunderstanding me. Did I not mention that the way to have _two_ ways to \nreference commits was ugly? You did not even bother to remove that part \nfrom what you quoted.\n\n> > A patch implementing a syntax like this would have won my unilateral \n> > approval\n> \n> I doubt this. You refused any changes to your idea and your code from \n> the beginning. You didn't answer questions and doesn't take part on the \n> discussion [1] about the new syntax.\n\nWell, you carefully ignored (but removed from the quoted text) my \nexplanation. Nevertheless, I did participate in the discussion, and \nmentioned my preferred way of doing things.\n\nSheesh,\nDscho\n"},{"id":"75395","messageId":"7vd4oac5qf.fsf@gitster.siamese.dyndns.org","threadId":"13285","inReplyTo":"alpine.DEB.1.00.0804281112500.2949@eeepc-johanness","subject":"Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-28T16:19:04Z","receivedAt":"2008-04-28T16:19:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> Maybe an example would help:\n>\n> -- snip --\n> pick abcdefg This is the first commit to be picked\n> reset cdefghij\n> pick zyxwvux A commit in a side-branch\n> merge recursive abcdefg\n> -- snap --\n\nIndeed it does. \"reset cdefghij\" --- does it reset to the exact cdefghij\ncommit, or cdefghij commit after rewriting?\n"},{"id":"75406","messageId":"20080428163003.GA6449@alea.gnuu.de","threadId":"13285","inReplyTo":"alpine.DEB.1.00.0804281409030.5399@eeepc-johanness","subject":"Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Jörg Sommer","fromEmail":"joerg@alea.gnuu.de","sentAt":"2008-04-28T16:30:03Z","receivedAt":"2008-04-28T16:30:03Z","isPatch":true,"sender":{"key":"joerg@alea.gnuu.de","avatar":null},"body":"Hi,\n\nJohannes Schindelin schrieb am Mon 28. Apr, 14:42 (+0100):\n> On Mon, 28 Apr 2008, Jörg Sommer wrote:\n> > Johannes Schindelin wrote:\n> > > On Sun, 27 Apr 2008, Junio C Hamano wrote:\n> > >\n> > >> Johannes Schindelin writes:\n> > >> \n> > >> > ... It did not help that I hated the fact that that series changed \n> > >> > the original design without even understanding it.\n> > >> \n> > >> Care to elaborate on this point further? I do not get it.\n> > >\n> > > The original implementation of -p was modeled closely after \n> > > filter-branch, in that it created a subdirectory (dotest/rewritten) \n> > > containing the new commit names for those commits that were rewritten.\n> > \n> > But that wasn't the way rebase -i works.\n> \n> I know exactly how it works. D'oh.\n> \n> > You had to jump in before pick_one does anything which clearly shows you \n> > did something different from the default way.\n> \n> That is bullshit. I did not do anything \"different from the default way\". \n> I carefully designed an interface that was easy to understand, because it \n> mimicked how you would do the same _by hand_, but without the hassle to \n> actually having to do everything by hand.\n> \n> In other words, rebase -i is just a cherry-pick in a loop.\n\nBut not rebase -i -p.\n\n> And _exactly_ the same should have been done for -p.\n\nBut you didn't do it.\n\n> Namely, _not_ introduce some artificial marks, but use the _commit\n> names_!\n\nI don't buy, you don't use marks (notes on paper or git tags) when you rebase\na branch with at least 8 commits and 2 merges.\n\nAnd Junio discribed how he would do such a rebase and it included marks.\nAnd I follow how. So no, they aren't artificial.\n\n> > > Now, whenever a commit was picked, the parents would be looked up in \n> > > dotest/rewritten, and replaced with the rewritten name (or left \n> > > unchanged if they were not rewritten).\n> > \n> > This approach doesn't work when you change the order of commits.\n> > Take the commit A, B and C in this order and reorder them to A C B:\n> > 1. pick A, A^ was not rewritten, nothing changed, A stays the same\n> > 2. pick C, C^ was not rewritten, nothing changed, C stays the same\n> > 3. pick B, B^ was not rewritten, nothing changed, B stays the same\n> \n> You carefully ignored how I intended the parents to be used: only for \n> merges.\n\nAnd why does this test fail? Please tell me, as you “know exactly how it\nworks.”\n\ndiff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh\nindex 9cf873f..83c2964 100755\n--- a/t/t3404-rebase-interactive.sh\n+++ b/t/t3404-rebase-interactive.sh\n@@ -361,4 +361,10 @@ test_expect_success 'rebase with a file named HEAD in worktree' '\n \n '\n \n+test_expect_success 'rebase with a file named HEAD in worktree' '\n+ head=$(git rev-parse HEAD) &&\n+ FAKE_LINES=\"1 3 2\" git rebase -i -p HEAD~3 &&\n+ test $(git rev-parse HEAD) != $head\n+'\n+\n test_done\n\n* FAIL 25: rebase with a file named HEAD in worktree\n\n head=$(git rev-parse HEAD) &&\n FAKE_LINES=\"1 3 2\" git rebase -i -p HEAD~3 &&\n test $(git rev-parse HEAD) != $head\n\n> > > Basically, the output of rebase -i -p is ugly now, because you have \n> > > _two_ ways of specifying things,\n> > \n> > > I have the feeling that I have to repeat my point again, so that it is not \n> > > ignored -- again. Maybe an example would help:\n> > >\n> > > -- snip --\n> > > pick abcdefg This is the first commit to be picked\n> > > reset cdefghij\n> > > pick zyxwvux A commit in a side-branch\n> > > merge recursive abcdefg\n\nWhere do you tell which merge should be redone?\n\n> > > -- snap --\n> > >\n> > > I am convinced that this syntax does not need much explanation.\n> > \n> > But above you said this syntax + mark is “ugly”. Strange.\n> \n> You know, I find it strange how you try to make a _point_ in \n> misunderstanding me. Did I not mention that the way to have _two_ ways to \n> reference commits was ugly? You did not even bother to remove that part \n> from what you quoted.\n\nBecause Junio told you about it. And I don't find your suggestion in\n very readable:\n\n| I would like it much better, if there was something like\n|\n| pick 5cc8f37 (init: show \"Reinit\" message even in ...)\n| pick 18d077c (quiltimport: fix misquoting of parse...)\n| merge 9876543:5cc8f37,18d077c (Merge blub)\n ^^^^^^^^^^^^^^^\n| reset 5cc8f37\n| ...\n\nI don't see why you complain about the marks and suggest to use\n9876543:5cc8f37,18d077c. In a short example like yours it doesn't hurd,\nbut put 10 line between the merge an the pick and maybe change move one\nof the merged commits behind the merge.\n\npick 8a785dc Add tests to catch problems with un-unlinkable symlinks\npick 8d14ac9 Test: catch if trash cannot be removed\npick 29dc133 git-merge-one-file: fix longstanding stupid thinko\npick deda26b Merge branch 'jc/makefile'\npick 7f8ab8d Don't update unchanged merge entries\npick 198724a fast-import: Allow \"reset\" to delete a new branch without error\npick 20fd60b t1000: use \"test_must_fail git frotz\", not \"! git frotz\"\npick 7092882 Update draft release notes for 1.5.5\npick c817faa Resurrect git-rerere to contrib/examples\npick 1eaa541 Merge branch 'maint'\npick 81d6650 Start draft ReleaseNotes for 1.5.4.5\nmerge 9876543:81d6650,198724a (Merge blub)\npick e637122 rebase -m: do not trigger pre-commit verification\n\npick 8a785dc Add tests to catch problems with un-unlinkable symlinks\npick 8d14ac9 Test: catch if trash cannot be removed\npick 29dc133 git-merge-one-file: fix longstanding stupid thinko\npick deda26b Merge branch 'jc/makefile'\npick 7f8ab8d Don't update unchanged merge entries\npick 198724a fast-import: Allow \"reset\" to delete a new branch without error\nmark #1\npick 20fd60b t1000: use \"test_must_fail git frotz\", not \"! git frotz\"\npick 7092882 Update draft release notes for 1.5.5\npick c817faa Resurrect git-rerere to contrib/examples\npick 1eaa541 Merge branch 'maint'\npick 81d6650 Start draft ReleaseNotes for 1.5.4.5\nmerge 9876543:81d6650,#1 (Merge blub)\npick e637122 rebase -m: do not trigger pre-commit verification\n\n> > > A patch implementing a syntax like this would have won my unilateral \n> > > approval\n> > \n> > I doubt this. You refused any changes to your idea and your code from \n> > the beginning. You didn't answer questions and doesn't take part on the \n> > discussion [1] about the new syntax.\n> \n> Well, you carefully ignored (but removed from the quoted text) my \n> explanation.\n\nSorry no, Junio made his proposal on Mar 24 and merge the code on Apr 25.\nI treat this as a adequate time window to propose a _better_ idea.\n\nBye, Jörg.\n-- \n“Unfortunately, the current generation of mail programs do not have\n checkers to see if the sender knows what he is talking about”\n (Andrew S. Tanenbaum)\n"},{"id":"75416","messageId":"alpine.DEB.1.00.0804281851520.19187@eeepc-johanness","threadId":"13285","inReplyTo":"7vd4oac5qf.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-28T18:01:32Z","receivedAt":"2008-04-28T18:01:32Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 28 Apr 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > Maybe an example would help:\n> >\n> > -- snip --\n> > pick abcdefg This is the first commit to be picked\n> > reset cdefghij\n> > pick zyxwvux A commit in a side-branch\n> > merge recursive abcdefg\n> > -- snap --\n> \n> Indeed it does. \"reset cdefghij\" --- does it reset to the exact cdefghij\n> commit, or cdefghij commit after rewriting?\n\nIn the example, it would be the original commit. However, a \"reset \nabcdefg\" _after_ the \"pick abcdefg\" line would refer to the _rewritten_ \ncommit.\n\nThe rationale: you are most likely not wanting to reference _both_ the \noriginal _and_ the rewritten commit.\n\nCiao,\nDscho\n"},{"id":"75417","messageId":"alpine.DEB.1.00.0804281902040.19187@eeepc-johanness","threadId":"13285","inReplyTo":"20080428163003.GA6449@alea.gnuu.de","subject":"Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-28T18:07:57Z","receivedAt":"2008-04-28T18:07:57Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 28 Apr 2008, Jörg Sommer wrote:\n\n> Johannes Schindelin schrieb am Mon 28. Apr, 14:42 (+0100):\n> > On Mon, 28 Apr 2008, Jörg Sommer wrote:\n> > > Johannes Schindelin wrote:\n> > > > On Sun, 27 Apr 2008, Junio C Hamano wrote:\n> > > >\n> > > >> Johannes Schindelin writes:\n> > > >> \n> > > >> > ... It did not help that I hated the fact that that series changed \n> > > >> > the original design without even understanding it.\n> > > >> \n> > > >> Care to elaborate on this point further? I do not get it.\n> > > >\n> > > > The original implementation of -p was modeled closely after \n> > > > filter-branch, in that it created a subdirectory (dotest/rewritten) \n> > > > containing the new commit names for those commits that were rewritten.\n> > > \n> > > But that wasn't the way rebase -i works.\n> > \n> > I know exactly how it works. D'oh.\n> > \n> > > You had to jump in before pick_one does anything which clearly shows you \n> > > did something different from the default way.\n> > \n> > That is bullshit. I did not do anything \"different from the default way\". \n> > I carefully designed an interface that was easy to understand, because it \n> > mimicked how you would do the same _by hand_, but without the hassle to \n> > actually having to do everything by hand.\n> > \n> > In other words, rebase -i is just a cherry-pick in a loop.\n> \n> But not rebase -i -p.\n\nYes. With the exception that you have to checkout and merge in the loop, \ntoo.\n\n> > And _exactly_ the same should have been done for -p.\n> \n> But you didn't do it.\n\nVery well done. If your intention is to piss me off: you succeeded.\n\n_OF COURSE_ I did not do it. That is why it was not working.\n\nBut you could have fixed that.\n\nInstead, you chose to complicate things.\n\n> > Namely, _not_ introduce some artificial marks, but use the _commit \n> > names_!\n> \n> I don't buy, you don't use marks (notes on paper or git tags) when you \n> rebase a branch with at least 8 commits and 2 merges.\n> \n> And Junio discribed how he would do such a rebase and it included marks. \n> And I follow how. So no, they aren't artificial.\n\nSo you again ignored completely the argument I made.\n\nBrilliant.\n\nThe same issue is _totally_ the same _without_ -p!\n\nAnd you cannot fix the problem by introducing another one.\n\nYou can try to complicate things even further, sure, but you will not \nchange the fact that this is no solution at all.\n\nWell, I refuse to let you insult my intelligence any more.\n\nCiao,\nDscho\n"},{"id":"75462","messageId":"7vprs9brlh.fsf@gitster.siamese.dyndns.org","threadId":"13285","inReplyTo":"alpine.DEB.1.00.0804281851520.19187@eeepc-johanness","subject":"Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-28T21:24:26Z","receivedAt":"2008-04-28T21:24:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Mon, 28 Apr 2008, Junio C Hamano wrote:\n>\n>> Johannes Schindelin writes:\n>> \n>> > Maybe an example would help:\n>> >\n>> > -- snip --\n>> > pick abcdefg This is the first commit to be picked\n>> > reset cdefghij\n>> > pick zyxwvux A commit in a side-branch\n>> > merge recursive abcdefg\n>> > -- snap --\n>> \n>> Indeed it does. \"reset cdefghij\" --- does it reset to the exact cdefghij\n>> commit, or cdefghij commit after rewriting?\n>\n> In the example, it would be the original commit. However, a \"reset \n> abcdefg\" _after_ the \"pick abcdefg\" line would refer to the _rewritten_ \n> commit.\n>\n> The rationale: you are most likely not wanting to reference _both_ the \n> original _and_ the rewritten commit.\n\nThat means moving the lines around inside the todo insn list makes the\nsame \"reset cdefghij\" mean different things.\n\nThat's insanity.\n\nAt least, if you use marks, you could detect a user error that references\na mark before it is defined.\n"},{"id":"75465","messageId":"alpine.DEB.1.00.0804282228270.19187@eeepc-johanness","threadId":"13285","inReplyTo":"7vprs9brlh.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-04-28T21:30:49Z","receivedAt":"2008-04-28T21:30:49Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 28 Apr 2008, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > On Mon, 28 Apr 2008, Junio C Hamano wrote:\n> >\n> >> Johannes Schindelin writes:\n> >> \n> >> > Maybe an example would help:\n> >> >\n> >> > -- snip --\n> >> > pick abcdefg This is the first commit to be picked\n> >> > reset cdefghij\n> >> > pick zyxwvux A commit in a side-branch\n> >> > merge recursive abcdefg\n> >> > -- snap --\n> >> \n> >> Indeed it does. \"reset cdefghij\" --- does it reset to the exact cdefghij\n> >> commit, or cdefghij commit after rewriting?\n> >\n> > In the example, it would be the original commit. However, a \"reset \n> > abcdefg\" _after_ the \"pick abcdefg\" line would refer to the _rewritten_ \n> > commit.\n> >\n> > The rationale: you are most likely not wanting to reference _both_ the \n> > original _and_ the rewritten commit.\n> \n> That means moving the lines around inside the todo insn list makes the\n> same \"reset cdefghij\" mean different things.\n> \n> That's insanity.\n\nI beg you pardon?\n\nConsider this history:\n\nA - B - C - D\n \\\n E - F\n\nNow, depending if B was rewritten or not, would you not want the reset \nbefore E to mean _different_ things?\n\nI.e. _if_ B is rewritten, E should branch off of the _rewritten_ B, but if \nB is _not_ rewritten, E should branch off of the original B?\n\nCiao,\nDscho\n"},{"id":"76850","messageId":"20080513091143.GA26248@sigill.intra.peff.net","threadId":"13285","inReplyTo":"e2b179460804280256g4ff903bu39c9460086df7157@mail.gmail.com","subject":"Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-05-13T09:11:43Z","receivedAt":"2008-05-13T09:11:43Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Apr 28, 2008 at 10:56:05AM +0100, Mike Ralphson wrote:\n\n> > If a failing test, then I wonder if we could get a few people to set up\n> > automated tests on alternate platforms. IIRC, Junio makes sure that\n> > master always passes test on his Linux box and KO (Debian and Redhat, I\n> > think?). Other platforms could \"git pull && make test\" daily. I could\n> > probably do Solaris (once I get the tests to complete pass at all!) and\n> > FreeBSD 6.\n> \n> I could run automated build / test [/ bisect?] cycles on AIX if of any\n> interest.\n\nI think that would be helpful. We seem to have most Linux variants\npretty well covered. I now have a daily pull/build/test running on a\nFreeBSD 6.1 box. I am going to try to get a Solaris one going, too, but\nI have to first actually get the test scripts to pass _once_. :)\n\nAIX would be nice, since it seems easy to break. ;) OS X would be nice,\ntoo, though I suspect there are a few developers (Shawn?) who end up\nrunning the test scripts occasionally anyway.\n\nI am just calling the script below through cron, and it dumps a bunch of\noutput if any test fails (at which point I go investigate manually). The\nonly argument is the path to a git repo.\n\n-- >8 --\n#!/bin/sh\n\ndir=$1; shift\nlog=\"$dir/.autotest.out\"\n\ntry() {\n \"$@\" >\"$log\" 2>&1\n case \"$?\" in\n 0) ;;\n *) echo >&2 \"autotest failed: $*\"\n cat >&2 \"$log\"\n exit 1\n ;;\n esac\n}\n\ntry cd \"$dir\"\ntry git pull\ntry gmake\nPATH=/usr/local/bin:/usr/bin:/bin; export PATH\ntry gmake test\n"},{"id":"76878","messageId":"e2b179460805131110k3cf582fdn9b8bd31046b90ca7@mail.gmail.com","threadId":"13285","inReplyTo":"20080513091143.GA26248@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Mike Ralphson","fromEmail":"mike.ralphson@gmail.com","sentAt":"2008-05-13T18:10:30Z","receivedAt":"2008-05-13T18:10:30Z","isPatch":true,"sender":{"key":"mike.ralphson@gmail.com","avatar":"https://avatars.githubusercontent.com/u/21603?v=4"},"body":"2008/5/13 Jeff King :\n>\n> On Mon, Apr 28, 2008 at 10:56:05AM +0100, Mike Ralphson wrote:\n> > I could run automated build / test [/ bisect?] cycles on AIX if of any\n> > interest.\n>\n> I think that would be helpful. We seem to have most Linux variants\n> pretty well covered. I now have a daily pull/build/test running on a\n> FreeBSD 6.1 box. I am going to try to get a Solaris one going, too, but\n> I have to first actually get the test scripts to pass _once_. :)\n>\n> AIX would be nice, since it seems easy to break. ;) OS X would be nice,\n> too, though I suspect there are a few developers (Shawn?) who end up\n> running the test scripts occasionally anyway.\n>\n> I am just calling the script below through cron, and it dumps a bunch of\n> output if any test fails (at which point I go investigate manually). The\n> only argument is the path to a git repo.\n\nThanks - that was a helpful spur to action. I'll check tomorrow how it\nfairs pulling, building, running the tests etc. I've added a couple of\n'try git tag -f's to it, so I have KNOWN_BUILDING and KNOWN_PASSING\npoints to pass quickly into bisect if necessary.\n\nI'll shout the first time something breaks (after doing a bit of\nrudimentary investigation), then maybe we can look at a way of\naggregating the build/test statuses and whether that should be pushed\nto a website (or git repo, obviously) or some kind of alert.\n\nCheers, Mike\n"},{"id":"77039","messageId":"e2b179460805150316n77513037y5409042b01170d4e@mail.gmail.com","threadId":"13285","inReplyTo":"e2b179460805131110k3cf582fdn9b8bd31046b90ca7@mail.gmail.com","subject":"Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Mike Ralphson","fromEmail":"mike.ralphson@gmail.com","sentAt":"2008-05-15T10:16:27Z","receivedAt":"2008-05-15T10:16:27Z","isPatch":true,"sender":{"key":"mike.ralphson@gmail.com","avatar":"https://avatars.githubusercontent.com/u/21603?v=4"},"body":"2008/5/13 Mike Ralphson :\n> Thanks - that was a helpful spur to action. I'll check tomorrow how it\n> fairs pulling, building, running the tests etc. I've added a couple of\n> 'try git tag -f's to it, so I have KNOWN_BUILDING and KNOWN_PASSING\n> points to pass quickly into bisect if necessary.\n\nMy KNOWN_BUILDING and KNOWN_PASSING tags are now happily chasing each\nother up the commit log.\n\nWhich branch(es) would it be most useful on which to have this\nautomated build/test cycle?\n\nAlthough the list of tags might get slightly unwieldy (i.e. the top\ncommit will gain a lot of tags if all is well), with a sensible naming\nconvention, these tags could be pushed to a central repo (a regularly\nupdated clone of git.git) allowing easy visibility of the current\nstate of the 'build collective'.\n\nSomething like {intials}_{uname info}_{branch}_KNOWN_{BUILDING|PASSING} ?\n\nMike\n"},{"id":"77041","messageId":"20080515112030.GA12781@sigill.intra.peff.net","threadId":"13285","inReplyTo":"e2b179460805150316n77513037y5409042b01170d4e@mail.gmail.com","subject":"Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-05-15T11:20:30Z","receivedAt":"2008-05-15T11:20:30Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 15, 2008 at 11:16:27AM +0100, Mike Ralphson wrote:\n\n> Which branch(es) would it be most useful on which to have this\n> automated build/test cycle?\n\nI would think maint, master, and next, but with next as the least\nimportant. I think Junio generally tests maint and master before\npublishing, but presumably not always next (as there was test breakage\nin next earlier today).\n\n> Although the list of tags might get slightly unwieldy (i.e. the top\n> commit will gain a lot of tags if all is well), with a sensible naming\n> convention, these tags could be pushed to a central repo (a regularly\n> updated clone of git.git) allowing easy visibility of the current\n> state of the 'build collective'.\n> \n> Something like {intials}_{uname info}_{branch}_KNOWN_{BUILDING|PASSING} ?\n\nI have started tagging my auto-builds as you suggest. It should be easy\nenough to push to a repo.or.cz repository. Although I'm not sure of the\nutility of auto-publishing this information. Who is going to look at it?\n\nI had assumed a workflow more like \"it passes 99% of the time; in the\nremaining 1%, the cron job kicks off a message to the owning user, who\nthen investigates and/or writes a bug report to the list.\"\n\nThat implies a little bit of expertise and work from the user owning the\nbuild, but:\n\n - presumably it won't happen very frequently\n\n - they are probably the only person with the resources to diganose and\n fix, anyway, since they are the ones with access to the platform.\n\n-Peff\n"},{"id":"77042","messageId":"20080515112319.GA13038@sigill.intra.peff.net","threadId":"13285","inReplyTo":"20080515112030.GA12781@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-05-15T11:23:19Z","receivedAt":"2008-05-15T11:23:19Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, May 15, 2008 at 07:20:30AM -0400, Jeff King wrote:\n\n> I have started tagging my auto-builds as you suggest. It should be easy\n> enough to push to a repo.or.cz repository. Although I'm not sure of the\n> utility of auto-publishing this information. Who is going to look at it?\n\nAlso, if there is interest in an automated \"this is now broken on\nplatform X\", I think the interesting thing is not \"what was the last\npassing state\" but rather \"what is the output of 'make test' for the\nfailing state.\" So:\n\n> I had assumed a workflow more like \"it passes 99% of the time; in the\n> remaining 1%, the cron job kicks off a message to the owning user, who\n> then investigates and/or writes a bug report to the list.\"\n\nIn that case, I think the interesting automation is making a problem\nreport from a failed case.\n\n-Peff\n"},{"id":"77054","messageId":"7vr6c3h4eb.fsf@gitster.siamese.dyndns.org","threadId":"13285","inReplyTo":"20080515112030.GA12781@sigill.intra.peff.net","subject":"Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-05-15T17:18:52Z","receivedAt":"2008-05-15T17:18:52Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Thu, May 15, 2008 at 11:16:27AM +0100, Mike Ralphson wrote:\n>\n>> Which branch(es) would it be most useful on which to have this\n>> automated build/test cycle?\n>\n> I would think maint, master, and next, but with next as the least\n> important. I think Junio generally tests maint and master before\n> publishing, but presumably not always next (as there was test breakage\n> in next earlier today).\n\nI'd prefer heterogeneous automated test coverage to be on 'next' and\n'master'. If the coverage extends to 'maint' that would be nicer, but on\nthe other hand, I rarely apply anything remotely questionable directly on\ntop of maint (instead, I'd fork from maint and merge the result first to\nnext or master), so if we can catch master and next, we should be Ok.\n\nBefore any push-out, I ran tests on all four integration branches on\nDebian (etch) and FC (I think it is FC5), both x86-64. But sometimes 'pu'\nis shipped with known breakage in tests. I can not push out with broken\ntests in 'maint', 'master' or 'next' (automated procedure on my end\nprevents me from doing so).\n"},{"id":"77136","messageId":"e2b179460805160722x654d80e0s2e37c4fa04ef0a27@mail.gmail.com","threadId":"13285","inReplyTo":"7vr6c3h4eb.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH 2/2] Fix t3404 assumption that `wc -l` does not use whitespace.","fromName":"Mike Ralphson","fromEmail":"mike.ralphson@gmail.com","sentAt":"2008-05-16T14:22:55Z","receivedAt":"2008-05-16T14:22:55Z","isPatch":true,"sender":{"key":"mike.ralphson@gmail.com","avatar":"https://avatars.githubusercontent.com/u/21603?v=4"},"body":"2008/5/15 Junio C Hamano :\n> I'd prefer heterogeneous automated test coverage to be on 'next' and\n> 'master'. If the coverage extends to 'maint' that would be nicer...\n>\n\nDo you have any interest in seeing the results of these automated\nbuilds? I'm thinking specifically of the case where you're about to\ntag a final release...\n\nObviously I'll shout on the list if/when we get a breakage.\n\nAn example of a tracking fork with the build/pass tags pushed to it is\nat http://repo.or.cz/w/git/gitbuild.git - unfortunately as the\nbranches are significant, the mob approach doesn't really work, so if\nanyone else would like to push tags to this repo, please just ask.\n\nMike\n"}]}