Tapasweni Pathak <tapaswenipathak@xxxxxxxxx> writes: >> > > As you can see "contrib/rerere-train.sh" is a 102 line long shell >> > > script, so converting it to a new `train` command in >> > > "builtin/rerere.c" seems like a not very difficult and not too big >> > > task (especially if done the same way as the script). Junio will >> > > likely be involved in this, as it looks like he is interested in it. >> > >> > Can I take it up immediately, if Junio is not working on it? >> > ++gitster@xxxxxxxxx. Hi Junio. Do you suggest otherwise? >> >> I don't want to speak for him, but I don't think he is working on it. >> In fact, as he suggested it for a GSoC, I think he doesn't plan to >> work on it soon. Also he might not answer often to emails that aren't >> also sent to the mailing list. s/answer/see/ actually. Other than that, everything you said is correct, Christian ;-) Mails to this mailbox that is not also going to the list are usually sent to the spambox. >> So if you want to work on it, I would suggest starting right away. You >> can of course send an email on the mailing list to let people know >> that you want to start working on this and to check if anyone is >> already working on it or has suggestions about it. Yes, that is a good advice. If we were doing 'git rerere train', especially outside GSoC, we would need to make sure we won't have to redo it later. A GSoC "easy" version of "git rerere train" would probably write a loop in C that repeatedly calls get_revision() to enumerate each merge commit in the given range, and in each iteration, spawns "git checkout --detach" to update the working tree and the index to that of its first parent, spawns "git merge" to try merging the other parent, and when it fails in conflict, updates the index and the working tree files to match what is recorded in the merge commit, and spawns "git rerere" to record that resolution. The thing is, many people on the list are unhappy with the approach various past GSoc and other tasks took to rewrite scripted Porcelain commands to C, spawning individual Git command just like the original scripts did. These people will be very unhappy with such a rewrite, I suspect, and would want it see done totally differently. Now we have ort merge machinery that can be used to implement in-core merges without touching neither the working tree or the index, a proper C rewrite of "git rerere train" should work quite differently from the scripted version, so "easy" version would likely be discarded and rewritten later. >> > > Another thing that was discussed recently is that the git-scm.org web >> > > site could be converted to not use Heroku anymore. If you prefer >> > > working on this kind of web oriented thing, this could be another >> > > possibility. >> > >> > I have worked a lot on web-based projects, SAAS, IAAS, PAAS, FAAS, >> > would it be better to share a proposal of comparison of those keeping >> > git-scm.org in mind, or is it pre-decided where git-scm.org will make >> > its new home/work? >> > >> > This shouldn't take more than 3 working days with no downtimes. >> >> Nice that you have some experience in this! Yup. This is not in my area of expertise, but it is very worthy work. If we can wean ourselves off of Heroku (the only thing we are doing is to serve a pretty much static website) sooner, it would be very good. >> I added Taylor in Cc as he is involved in this and might answer your >> questions much better than me. Now if you are interested in it, I >> suggest starting right away and perhaps also sending an email to the >> mailing list asking your questions and asking for advice there. > > Hi Taylor. Great if you can let me know what you want to see > happening, and if we can discuss tech specifications, you have already > decided or plan to.
