{"thread":{"id":"52500","subject":"Propose promoting 'contrib/rerere-train.sh' to command","startedAt":"2019-12-21T02:19:32Z","lastAt":"2020-01-01T22:07:24Z","messageCount":8,"participants":["Tom Miller","Philip Oakley","Jeff King","Junio C Hamano","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"388700","messageId":"BZAQIE4YND2I.Z7BFCW7BLH3K@penguin","threadId":"52500","inReplyTo":null,"subject":"Propose promoting 'contrib/rerere-train.sh' to command","fromName":"Tom Miller","fromEmail":"jackerran@gmail.com","sentAt":"2019-12-21T02:17:57Z","receivedAt":"2019-12-21T02:19:32Z","isPatch":false,"sender":{"key":"jackerran@gmail.com","avatar":null},"body":"I would like to propose promoting 'contrib/rerere-train.sh' to one of the\nfollowing:\n\n 1. A builtin c command 'builtin/rerere-train.c'\n 2. To the top level directory as a built in script 'git-rerere-train.sh'\n\nI have recently found myself writing scripts using 'contrib/rerere-train.sh'\nand I wish it was built into the command. This would make it easier to use\nrather than having to find it on different platforms. I think it could also\nbenefit from some documentation.\n\nI am trying to gauge the interest in this change before spending some time on\nworking on it. I would also appreciate feedback or alternative approaches to\nwhat I have suggested. Thank you for your time.\n\nThanks,\nTom Miller\n"},{"id":"388712","messageId":"7b60ce55-700e-0c67-76ac-a983991e49f2@iee.email","threadId":"52500","inReplyTo":"BZAQIE4YND2I.Z7BFCW7BLH3K@penguin","subject":"Re: Propose promoting 'contrib/rerere-train.sh' to command","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2019-12-21T17:00:48Z","receivedAt":"2019-12-21T17:00:50Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"Hi Tom,\n\nOn 21/12/2019 02:17, Tom Miller wrote:\n> I would like to propose promoting 'contrib/rerere-train.sh' to one of the\n> following:\n>\n> 1. A builtin c command 'builtin/rerere-train.c'\n> 2. To the top level directory as a built in script 'git-rerere-train.sh'\n>\n> I have recently found myself writing scripts using 'contrib/rerere-train.sh'\n> and I wish it was built into the command. This would make it easier to use\n> rather than having to find it on different platforms. I think it could also\n> benefit from some documentation.\n>\n> I am trying to gauge the interest in this change before spending some time on\n> working on it. I would also appreciate feedback or alternative approaches to\n> what I have suggested. Thank you for your time.\n>\n> Thanks,\n> Tom Miller\nThis sounds like a useful capability (especially the documentation!).\n\nI also had aspirations that there should also be a way of exchanging the\nessence of the rerere data when conflicts (e.g. feature vs master branch\nmerges) are known locally and ought to be communicable with the patch sets.\n\nsee messages:\n<37ccaad0-40b4-ca63-e057-791119d7fa69@talktalk.net>\n\n\nPhilip\n"},{"id":"388713","messageId":"8a84be21-e512-ac42-3426-524afb92ba9b@iee.email","threadId":"52500","inReplyTo":"7b60ce55-700e-0c67-76ac-a983991e49f2@iee.email","subject":"Re: Propose promoting 'contrib/rerere-train.sh' to command","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.email","sentAt":"2019-12-21T17:37:46Z","receivedAt":"2019-12-21T17:45:54Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 21/12/2019 17:00, Philip Oakley wrote:\n> Hi Tom,\n>\n> On 21/12/2019 02:17, Tom Miller wrote:\n>> I would like to propose promoting 'contrib/rerere-train.sh' to one of the\n>> following:\n>>\n>> 1. A builtin c command 'builtin/rerere-train.c'\n>> 2. To the top level directory as a built in script 'git-rerere-train.sh'\n>>\n>> I have recently found myself writing scripts using 'contrib/rerere-train.sh'\n>> and I wish it was built into the command. This would make it easier to use\n>> rather than having to find it on different platforms. I think it could also\n>> benefit from some documentation.\n>>\n>> I am trying to gauge the interest in this change before spending some time on\n>> working on it. I would also appreciate feedback or alternative approaches to\n>> what I have suggested. Thank you for your time.\n>>\n>> Thanks,\n>> Tom Miller\n> This sounds like a useful capability (especially the documentation!).\n>\n> I also had aspirations that there should also be a way of exchanging the\n> essence of the rerere data when conflicts (e.g. feature vs master branch\n> merges) are known locally and ought to be communicable with the patch sets.\n>\n> see messages:\n> <37ccaad0-40b4-ca63-e057-791119d7fa69@talktalk.net>\n> \n>\n> Philip\nThere is also audio of the section of the Virtual Conf in a personal\nemail <20190914165929.GA22300@sigill.intra.peff.net> (~30MB) if needed.\n"},{"id":"388717","messageId":"20191221193110.GB3339249@coredump.intra.peff.net","threadId":"52500","inReplyTo":"BZAQIE4YND2I.Z7BFCW7BLH3K@penguin","subject":"Re: Propose promoting 'contrib/rerere-train.sh' to command","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-12-21T19:31:10Z","receivedAt":"2019-12-21T19:31:12Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Dec 20, 2019 at 08:17:57PM -0600, Tom Miller wrote:\n\n> I would like to propose promoting 'contrib/rerere-train.sh' to one of the\n> following:\n> \n> 1. A builtin c command 'builtin/rerere-train.c'\n> 2. To the top level directory as a built in script 'git-rerere-train.sh'\n> \n> I have recently found myself writing scripts using 'contrib/rerere-train.sh'\n> and I wish it was built into the command. This would make it easier to use\n> rather than having to find it on different platforms. I think it could also\n> benefit from some documentation.\n> \n> I am trying to gauge the interest in this change before spending some time on\n> working on it. I would also appreciate feedback or alternative approaches to\n> what I have suggested. Thank you for your time.\n\nThe situations where I need rerere-train don't come up often, but when\nthey do, it has always worked easily and without hiccups for me. So\nperhaps there are lurking gotchas that Junio might know about, but AFAIK\nthe quality is high enough for it to be part of normal Git.\n\nI'd suggest converting it to C and making it a sub-command of rerere\n(i.e., \"git rerere train a..b\") rather than a separate command.\n\nIt would be a nice bonus if it could do its work internally by looking\nat the commits, rather than munging the working tree through checkout\nand merge. I'm not sure how easy that would be, though. Historically the\nmerge-recursive machinery has not worked well without having a working\ntree to dump the conflicted paths into, but I think that has gotten\nsomewhat better recently. So even a straight C conversion of the shell\nscript would be an OK starting point, I think.\n\n-Peff\n"},{"id":"388769","messageId":"xmqqeewx6xt6.fsf@gitster-ct.c.googlers.com","threadId":"52500","inReplyTo":"20191221193110.GB3339249@coredump.intra.peff.net","subject":"Re: Propose promoting 'contrib/rerere-train.sh' to command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2019-12-21T23:52:53Z","receivedAt":"2019-12-21T23:53:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> The situations where I need rerere-train don't come up often, but when\n> they do, it has always worked easily and without hiccups for me. So\n> perhaps there are lurking gotchas that Junio might know about, but AFAIK\n> the quality is high enough for it to be part of normal Git.\n\nI actually suspect that rewriting has a high chance of initially\ndegrading the quality, so we should take a two step approach if we\nreally want it as part of the core distribution. As to the UI, I\nthink \"git rerere train a..b\" would be a good one, but if the\nscripted version is of high quality (I haven't looked at it for a\nlong time---even though I used it for a couple of times a year in\nrecent years), perhaps we can add it as \"git-rerere--train\"\nsubcommand that is spawned from \"builtin/rerere.c\" for the first\ncut?\n\n> I'd suggest converting it to C and making it a sub-command of rerere\n> (i.e., \"git rerere train a..b\") rather than a separate command.\n"},{"id":"388786","messageId":"20191222075836.GA3425263@coredump.intra.peff.net","threadId":"52500","inReplyTo":"xmqqeewx6xt6.fsf@gitster-ct.c.googlers.com","subject":"Re: Propose promoting 'contrib/rerere-train.sh' to command","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-12-22T07:58:36Z","receivedAt":"2019-12-22T07:58:39Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Dec 21, 2019 at 03:52:53PM -0800, Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n> > The situations where I need rerere-train don't come up often, but when\n> > they do, it has always worked easily and without hiccups for me. So\n> > perhaps there are lurking gotchas that Junio might know about, but AFAIK\n> > the quality is high enough for it to be part of normal Git.\n> \n> I actually suspect that rewriting has a high chance of initially\n> degrading the quality, so we should take a two step approach if we\n> really want it as part of the core distribution. As to the UI, I\n> think \"git rerere train a..b\" would be a good one, but if the\n> scripted version is of high quality (I haven't looked at it for a\n> long time---even though I used it for a couple of times a year in\n> recent years), perhaps we can add it as \"git-rerere--train\"\n> subcommand that is spawned from \"builtin/rerere.c\" for the first\n> cut?\n\nYeah, I'd be pretty happy with that, too.\n\nI just suspect its ultimate fate is conversion to C, given the general\ntrend. And converting it to C that just calls out to other git commands\nvia run_command would presumably behave just like the original, leaving\nthe more challenging and error-prone conversion for later. Hopefully any\nupgrade to \"real Git command\" would include some tests, though. :)\n\n-Peff\n"},{"id":"388795","messageId":"BZBZ3Y9WU7J7.3PGDZKEYVQ165@penguin","threadId":"52500","inReplyTo":"20191222075836.GA3425263@coredump.intra.peff.net","subject":"Re: Propose promoting 'contrib/rerere-train.sh' to command","fromName":"Tom Miller","fromEmail":"jackerran@gmail.com","sentAt":"2019-12-22T13:14:55Z","receivedAt":"2019-12-22T13:27:30Z","isPatch":false,"sender":{"key":"jackerran@gmail.com","avatar":null},"body":"On Sun Dec 22, 2019 at 2:58 AM, Jeff King wrote:\n> On Sat, Dec 21, 2019 at 03:52:53PM -0800, Junio C Hamano wrote:\n>\n> \n> > Jeff King writes:\n> > \n> > > The situations where I need rerere-train don't come up often, but when\n> > > they do, it has always worked easily and without hiccups for me. So\n> > > perhaps there are lurking gotchas that Junio might know about, but AFAIK\n> > > the quality is high enough for it to be part of normal Git.\n> > \n> > I actually suspect that rewriting has a high chance of initially\n> > degrading the quality, so we should take a two step approach if we\n> > really want it as part of the core distribution. As to the UI, I\n> > think \"git rerere train a..b\" would be a good one, but if the\n> > scripted version is of high quality (I haven't looked at it for a\n> > long time---even though I used it for a couple of times a year in\n> > recent years), perhaps we can add it as \"git-rerere--train\"\n> > subcommand that is spawned from \"builtin/rerere.c\" for the first\n> > cut?\n>\n> \n> Yeah, I'd be pretty happy with that, too.\n>\n> \n> I just suspect its ultimate fate is conversion to C, given the general\n> trend. And converting it to C that just calls out to other git commands\n> via run_command would presumably behave just like the original, leaving\n> the more challenging and error-prone conversion for later. Hopefully any\n> upgrade to \"real Git command\" would include some tests, though. :)\n>\n> \n> -Peff\n\nThanks for the feedback everyone! This is roughly the feedback I\nexpected. I think moving the shell version first will give more time to\nfocus on getting a strong test harness in place and a some decent\ndocumentation. I happy with doing this in a multi phase approach as it\nintroduces less risk. When I get to the point of writing it in C I will\ntry to do the work internally by looking at commits as Jeff has\nsuggested, and fall back to run commands if I have to.\n"},{"id":"389154","messageId":"nycvar.QRO.7.76.6.2001012303240.46@tvgsbejvaqbjf.bet","threadId":"52500","inReplyTo":"BZBZ3Y9WU7J7.3PGDZKEYVQ165@penguin","subject":"Re: Propose promoting 'contrib/rerere-train.sh' to command","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-01-01T22:06:53Z","receivedAt":"2020-01-01T22:07:24Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sun, 22 Dec 2019, Tom Miller wrote:\n\n> On Sun Dec 22, 2019 at 2:58 AM, Jeff King wrote:\n> > On Sat, Dec 21, 2019 at 03:52:53PM -0800, Junio C Hamano wrote:\n> >\n> >\n> > > Jeff King writes:\n> > >\n> > > > The situations where I need rerere-train don't come up often, but when\n> > > > they do, it has always worked easily and without hiccups for me. So\n> > > > perhaps there are lurking gotchas that Junio might know about, but AFAIK\n> > > > the quality is high enough for it to be part of normal Git.\n> > >\n> > > I actually suspect that rewriting has a high chance of initially\n> > > degrading the quality, so we should take a two step approach if we\n> > > really want it as part of the core distribution. As to the UI, I\n> > > think \"git rerere train a..b\" would be a good one, but if the\n> > > scripted version is of high quality (I haven't looked at it for a\n> > > long time---even though I used it for a couple of times a year in\n> > > recent years), perhaps we can add it as \"git-rerere--train\"\n> > > subcommand that is spawned from \"builtin/rerere.c\" for the first\n> > > cut?\n> >\n> >\n> > Yeah, I'd be pretty happy with that, too.\n> >\n> >\n> > I just suspect its ultimate fate is conversion to C, given the general\n> > trend. And converting it to C that just calls out to other git commands\n> > via run_command would presumably behave just like the original, leaving\n> > the more challenging and error-prone conversion for later. Hopefully any\n> > upgrade to \"real Git command\" would include some tests, though. :)\n> >\n> >\n> > -Peff\n>\n> Thanks for the feedback everyone! This is roughly the feedback I\n> expected. I think moving the shell version first will give more time to\n> focus on getting a strong test harness in place and a some decent\n> documentation. I happy with doing this in a multi phase approach as it\n> introduces less risk. When I get to the point of writing it in C I will\n> try to do the work internally by looking at commits as Jeff has\n> suggested, and fall back to run commands if I have to.\n\nAs the person who traditionally ends up being stuck with such conversions,\nI would like to point out that the rerere-train script has not changed _in\nyears_ and that there is little point in trying to let it \"cook\" some more\nin the scripted form, _in particular_ because this would prevent the\ncommand from having access to the more powerful C API for future\nimprovements.\n\nOne very obvious enhancement would be to perform the training in memory,\nwithout even clobbering the worktree. That's simply not a thing that a\nshell script can perform.\n\nFood for thought,\nDscho\n"}]}