[GSoC] Proposal Discussion

[GSoC] Proposal Discussion

[Devin Lehmacher]

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.

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?

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?

[1]: https://public-inbox.org/git/20170320164154.xBcU6rG0C%25pickfire@riseup.net/
[2]: https://public-inbox.org/git/CA+P7+xr4ZNCCJkS0=yR-FNu+MrL60YX-+Wsz9L_5LCNhnY_d=A@mail.gmail.com/

Thanks for any feedback you may have,
Devin

Re: [GSoC] Proposal Discussion

[Christian Couder]

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.

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

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

Re: [GSoC] Proposal Discussion

[Devin Lehmacher]

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