Re: [GSoC] Proposal Discussion

[Devin Lehmacher <lehmacdj@gmail.com>]

On Tue, Mar 28, 2017 at 07:52:42AM +0200, Christian Couder wrote:
> Hi,
>
> On Tue, Mar 28, 2017 at 12:17 AM, Devin Lehmacher <lehmacdj@gmail.com> wrote:
> > Hello everyone,
> >
> > I am a student studying Computer Science at Cornell University. I
> > already completed a microproject, Move ~/.git-credential-cache/socket to
> > $XDG_CACHE_HOME/credential/socket a week and a half ago or so.
>
> Nice. It would be better though if you could provide a link to the
> thread where your microproject was discussed. If it has been merged to
> master, you could also provide the merge commit. Otherwise please tell
> what is its branch name and current status in the last "What's cooking
> in git.git" email from Junio.

Here is the merge commit into master: 78cf8efec34c419ecea86bc8d1fe47ec0b51ba37

> > I am interested in 2 different projects and would like some advice on
> > them, to help me decide which one to submit a proposal for.
> >
> > 1. `git rebase -i` conversion.
> >    I was initially the most interested in this project but realize that
> >    after having a very busy week last week that Ivan Tham started
> >    [discussion][1] about this project. Would it be appropriate to submit
> >    a proposal for a project that someone else also wants to work on?
>
> Yes, it is ok. Obviously only one student/proposal can be selected for
> a given project, but as anyway the main constraint for us is usually
> the number of available mentors, there is a low chance that this would
> prevent us from selecting one more student than we could otherwise
> select.
>
> You could also submit 2 proposals if you have time to work on more than one.

Ok! I think I will post rough drafts of both proposals sometime tomorrow
or maybe later today if I have time.

> > 2. formatting tool improvements.
> >    There are four different git commands mentioned [here][2] as possible
> >    tools to improve as can be seen in the email. Of those I think it
> >    would make the most sense to extend `git name-rev`. It seems best
> >    suited to the desired behavior. It would need to be extended to
> >    understand rev's that refer to objects rather than just a commit-ish
> >    and also add formatting support similar to the information that log
> >    and for-each-ref can output. Since this doesn't seem like much work,
> >    would it be feasible to generalize and somewhat standardize all of
> >    the formatting commands?
>
> Yeah, I think it would be good. It might involve a lot of discussion
> though and this could slow your project.
> So if you really want to do it, my advice is to try to start the
> discussion as soon as possible, that is now.
>
> To do that you could for example Cc people involved in the email
> discussions, and try to come up with concrete proposals about how to
> generalize and standardize the formatting commands.

I will try to send out an email later this afternoon with a preliminary
plan and to start discussion about how best to rework formatting
commands.

Thanks,
Devin