Re: Unify ref-filter formats with other pretty formats: GSoC'22

[Junio C Hamano <gitster@pobox.com>]

Tapasweni Pathak <tapaswenipathak@gmail.com> 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@pobox.com. 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.