Re: Git GSoC 2014

[Jeff King <peff@peff.net>]

On Thu, Feb 13, 2014 at 06:17:17PM -0500, Ramkumar Ramachandra wrote:

> I'll throw in a few ideas from half-finished work.

Thanks. A few comments:

> 1. Speed up git-rebase--am.sh
> 
> Currently, git-rebase--am.sh is really slow because it dumps each
> patch to a file using git-format-patch, and picks it up to apply
> subsequently using git-am. Find a way to speed this up, without
> sacrificing safety. You can use the continuation features of
> cherry-pick, and dump to file only to persist state in the case of a
> failure.

Isn't the merge backend faster? I thought that was the point of it.

> 3. Rewrite git-branch to use git-for-each-ref
> 
> For higher flexibility in command-line options and output format, use
> git for-each-ref to re-implement git-branch. The first task is to grow
> features that are in branch but not fer into fer (like --column,
> --merged, --contains). The second task is to refactor fer so that an
> external program can call into it.

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).

> 4. Implement @{publish}
> (I just can't find the time to finish this)
> 
> @{publish} is a feature like @{upstream}, showing the state of the
> publish-point in the case of triangular workflows. Implement this
> while sharing code with git-push, and polish it until the prompt shows
> publish-state.

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).

-Peff