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?
>> 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.
>> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
