Re: [GSoC] Proposal Discussion

From: Christian Couder <christian.couder@gmail.com>
Date: Mar 28, 2017, 05:52 UTC
Message-ID: <CAP8UFD19+-xB-tPnY8Njfyci=wztnoZsEgx0UTqrJBEeTj_X-w@mail.gmail.com>
In-Reply-To: <20170327221707.GA34039@mango1>

Hi,

On Tue, Mar 28, 2017 at 12:17 AM, Devin Lehmacher <lehmacdj@gmail.com> wrote:

Show 5 quoted lines

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

Show 8 quoted lines

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

Show 10 quoted lines

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

Thanks, Christian.