Re: Git GSoC 2014

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Feb 14, 2014, 15:30 UTC
Message-ID: <CALkWK0nXbfoe7697m27o7b+vepkOWj+vpJJWRy9EkJeZkTyekw@mail.gmail.com>
In-Reply-To: <20140214104139.GA28570@sigill.intra.peff.net>

Jeff King wrote:

>> 1. Speed up git-rebase--am.sh
>
> Isn't the merge backend faster? I thought that was the point of it.

I suppose, but I thought git-rebase--am.sh (the default flavor) could be improved by leveraging relatively new cherry-pick features; I assumed that the reason it was using format-patch/ am was because it was written before cherry-pick matured. Alternatively, can you think of a project that involves working on the sequencer?

Show 6 quoted lines

>> 3. Rewrite git-branch to use git-for-each-ref
>
> I actually have this about 95% done, waiting for the patches to be
> polished. So I don't think it makes a good GSoC project (it would be
> stupid to start from scratch, and polishing my patches is a lame
> project).

Oh. I look forward to using a nicer git-branch soon.

Show 7 quoted lines

>> 4. Implement @{publish}
>
> I think this could be a good GSoC-sized topic. I'm going to adjust the
> title to be "better support for triangular workflows". I think they may
> want to examine other issues in the area, rather than drilling down on
> @{publish} in particular (but ultimately, it is up to the student to
> propose what they want to do).

That makes the project a little more open-ended then. I like it.

I was hoping you'd have more comments on "3. Invent new conflict style". Although I'm not sure the conflict style I proposed would be terribly useful in the general case, it'll give the student an opportunity to look at older/ lesser-known portions of the codebase.