On Fri, Dec 20, 2019 at 08:17:57PM -0600, Tom Miller wrote: > I would like to propose promoting 'contrib/rerere-train.sh' to one of the > following: > > 1. A builtin c command 'builtin/rerere-train.c' > 2. To the top level directory as a built in script 'git-rerere-train.sh' > > I have recently found myself writing scripts using 'contrib/rerere-train.sh' > and I wish it was built into the command. This would make it easier to use > rather than having to find it on different platforms. I think it could also > benefit from some documentation. > > I am trying to gauge the interest in this change before spending some time on > working on it. I would also appreciate feedback or alternative approaches to > what I have suggested. Thank you for your time. The situations where I need rerere-train don't come up often, but when they do, it has always worked easily and without hiccups for me. So perhaps there are lurking gotchas that Junio might know about, but AFAIK the quality is high enough for it to be part of normal Git. I'd suggest converting it to C and making it a sub-command of rerere (i.e., "git rerere train a..b") rather than a separate command. It would be a nice bonus if it could do its work internally by looking at the commits, rather than munging the working tree through checkout and merge. I'm not sure how easy that would be, though. Historically the merge-recursive machinery has not worked well without having a working tree to dump the conflicted paths into, but I think that has gotten somewhat better recently. So even a straight C conversion of the shell script would be an OK starting point, I think. -Peff
