Hi Alban, thank you for your proposal! I will only comment on the parts that I feel could use improvement, the rest is fine by me. On Sat, 17 Mar 2018, Alban Gruin wrote: > APPROXIMATIVE TIMELINE > > Community bonding — April 23, 2018 – May 14, 2018 > During the community bonding, I would like to dive into git’s codebase, > and to understand what git-rebase--interactive does under the hood. At > the same time, I’d communicate with the community and my mentor, seeking > for clarifications, and asking questions about how things should or > should not be done. > > Weeks 1 & 2 — May 14, 2018 – May 28, 2018 > First, I would refactor --preserve-merges in its own shell script, as > described in Dscho’s email. Could you go into detail a bit here? Like, describe what parts of the git-rebase--interactive.sh script would need to be duplicated, which ones would be truly moved, etc > Weeks 3 & 4 — May 18, 2018 – June 11, 2018 > Then, I would start to rewrite git-rebase--interactive, and get rid of git- > rebase--helper. I think this is a bit premature, as the rebase--helper would not only serve the --interactive part, but in later conversions also --am and --merge, and only in the very end, when git-rebase.sh gets converted, would we be able to simply rename the rebase--helper to rebase. Also, I have a hunch that there is actually almost nothing left to rewrite after my sequencer improvements that made it into Git v2.13.0, together with the upcoming changes (which are on top of the --recreate-merges patch series, hence I did not send them to the mailing list yet) in https://github.com/dscho/git/commit/c261f17a4a3e So I would like to see more details here... ;-) > Weeks 5 to 9 — June 11, 2018 – July 15, 2018 > During this period, I would continue to rewrite git-rebase--interactive. It would be good if the proposal said what parts of the conversion are tricky, to merit spending a month on them. > Weeks 10 & 11 — July 16, 2018 – July 29, 2018 > In the second half of July, I would look for bugs in the new code, test it, > and improve its coverage. As I mentioned in a related mail, the test suite coverage would be most sensibly extended *before* starting to rewrite code in C, as it helps catching bugs early and avoids having to merge buggy code that needs to be fixed immediately. > Weeks 12 — July 30, 2018 – August 5, 2018 > In the last week, I would polish the code where needed, in order to > improve for performance or to make the code more readable. Thank you for sharing this draft with us! Johannes
