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