[RFH] GSoC 2015 application

[RFH] GSoC 2015 application

[Jeff King]

The response to my previous email was not overwhelming, but people did
express some interest in Git doing GSoC this year. So I've started on
the application, using last year's version as a template.

The materials are all in:

  https://github.com/git/git.github.io

If you'd like to help, I'm happy to take emailed patches, pull requests,
or just plain-English suggestions. If you want push access to that
repository, email me.

A draft of the application is here:

  http://git.github.io/SoC-2015-Org-Application.html

The questions are the same as last year, so with the exception of some
reviewing and updating for the new year, this shouldn't be too much
work. I do need somebody to volunteer as backup admin. This doesn't need
to involve any specific commitment, but is mostly about what to do if I
get hit by a bus. Of course helping with application review,
coordinating mentors, etc, is welcome from the backup admin.

Where I really need help now is in the "ideas" page:

  http://git.github.io/SoC-2015-Ideas.html

and the list of microprojects:

  http://git.github.io/SoC-2015-Microprojects.html

Note that I've listed microprojects as required for students this year
(whereas last year, we only strongly encouraged them). I think they
worked very well, but that requirement is up for debate.

We may be able to port over ideas or microprojects from last year, but I
want to do so only after somebody has confirmed that they are still in
need of doing. And of course new ideas and microprojects are very
welcome.

The students will not begin looking at these until the participating
projects are announced. But the GSoC folks _will_ be looking at the
Ideas page, which is linked from the application. So while we can tweak
it later, it needs to have content now (in the next 48 hours). So if you
must choose which to focus your efforts on, do Ideas first.

-Peff

Re: [RFH] GSoC 2015 application

[Jeff King]

Cc-ing this to the msysgit list, which I should have done in the first
place. Certainly ideas specific to Git for Windows would be welcome.

On Wed, Feb 18, 2015 at 02:14:17PM -0500, Jeff King wrote:

> The response to my previous email was not overwhelming, but people did
> express some interest in Git doing GSoC this year. So I've started on
> the application, using last year's version as a template.
> 
> The materials are all in:
> 
>   https://github.com/git/git.github.io
> 
> If you'd like to help, I'm happy to take emailed patches, pull requests,
> or just plain-English suggestions. If you want push access to that
> repository, email me.
> 
> A draft of the application is here:
> 
>   http://git.github.io/SoC-2015-Org-Application.html
> 
> The questions are the same as last year, so with the exception of some
> reviewing and updating for the new year, this shouldn't be too much
> work. I do need somebody to volunteer as backup admin. This doesn't need
> to involve any specific commitment, but is mostly about what to do if I
> get hit by a bus. Of course helping with application review,
> coordinating mentors, etc, is welcome from the backup admin.
> 
> Where I really need help now is in the "ideas" page:
> 
>   http://git.github.io/SoC-2015-Ideas.html
> 
> and the list of microprojects:
> 
>   http://git.github.io/SoC-2015-Microprojects.html
> 
> Note that I've listed microprojects as required for students this year
> (whereas last year, we only strongly encouraged them). I think they
> worked very well, but that requirement is up for debate.
> 
> We may be able to port over ideas or microprojects from last year, but I
> want to do so only after somebody has confirmed that they are still in
> need of doing. And of course new ideas and microprojects are very
> welcome.
> 
> The students will not begin looking at these until the participating
> projects are announced. But the GSoC folks _will_ be looking at the
> Ideas page, which is linked from the application. So while we can tweak
> it later, it needs to have content now (in the next 48 hours). So if you
> must choose which to focus your efforts on, do Ideas first.
> 
> -Peff

Re: Re: [RFH] GSoC 2015 application

[Johannes Schindelin]

Hi Peff,

On 2015-02-18 20:32, Jeff King wrote:

> On Wed, Feb 18, 2015 at 02:14:17PM -0500, Jeff King wrote:
> 
>> The response to my previous email was not overwhelming, but people did
>> express some interest in Git doing GSoC this year. So I've started on
>> the application, using last year's version as a template.

I feel unqualified to fill in the information, having kept out of the loop of the past years' GSoC efforts.

After considerable consideration, I am offering to mentor Windows-related projects (into which I count conversion of scripts into builtins).

Thanks,
Dscho

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Git for Windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Jeff King]

On Tue, Feb 24, 2015 at 01:01:17PM +0100, Johannes Schindelin wrote:

> After considerable consideration, I am offering to mentor
> Windows-related projects (into which I count conversion of scripts
> into builtins).

Thanks! No rush, as we are not even accepted yet, but you can create a
profile at:

  http://google-melange.com

and ask to join the "git" project as a mentor.

You may also want to add Windows-specific ideas to the page at:

  https://github.com/git/git.github.io/blob/master/SoC-2015-Ideas.md

Even something high-level like "helping move programs to builtins to
help Windows" will let students know that it's a potential direction.

-Peff

Re: Re: [RFH] GSoC 2015 application

[Johannes Schindelin]

Hi Peff,

On 2015-02-24 13:06, Jeff King wrote:
> On Tue, Feb 24, 2015 at 01:01:17PM +0100, Johannes Schindelin wrote:
> 
>> After considerable consideration, I am offering to mentor
>> Windows-related projects (into which I count conversion of scripts
>> into builtins).
> 
> Thanks! No rush, as we are not even accepted yet, but you can create a
> profile at:
> 
>   http://google-melange.com
> 
> and ask to join the "git" project as a mentor.

I guess I can only ask that after the org is accepted, I will do so when (and if) that is the case.

> You may also want to add Windows-specific ideas to the page at:
> 
>   https://github.com/git/git.github.io/blob/master/SoC-2015-Ideas.md
> 
> Even something high-level like "helping move programs to builtins to
> help Windows" will let students know that it's a potential direction.

Done: https://github.com/git/git.github.io/pull/12

Thank you,
Dscho

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Git for Windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Jeff King]

On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote:

> > Thanks! No rush, as we are not even accepted yet, but you can create a
> > profile at:
> > 
> >   http://google-melange.com
> > 
> > and ask to join the "git" project as a mentor.
> 
> I guess I can only ask that after the org is accepted, I will do so
> when (and if) that is the case.

I think you can do it now; I had to create the project profile in order
to do the application. But again, no rush.

> Done: https://github.com/git/git.github.io/pull/12

Thanks, merged.

-Peff

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Johannes Schindelin]

Hi Peff,

On 2015-02-24 13:28, Jeff King wrote:
> On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote:
> 
>> > Thanks! No rush, as we are not even accepted yet, but you can create a
>> > profile at:
>> >
>> >   http://google-melange.com
>> >
>> > and ask to join the "git" project as a mentor.
>>
>> I guess I can only ask that after the org is accepted, I will do so
>> when (and if) that is the case.
> 
> I think you can do it now; I had to create the project profile in order
> to do the application. But again, no rush.

I tried, but there are no orgs listed as of yet when I click "Make connection".

>> Done: https://github.com/git/git.github.io/pull/12
> 
> Thanks, merged.

I opened another PR, based on Mathieu's advice.

Ciao,
Dscho

Re: Re: [RFH] GSoC 2015 application

[Matthieu Moy]

Johannes Schindelin <johannes.schindelin@gmx.de> writes:

>>> Done: https://github.com/git/git.github.io/pull/12
>> 
>> Thanks, merged.
>
> I opened another PR, based on Mathieu's advice.

Thanks, merged.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Git for Windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re: [RFH] GSoC 2015 application

[Matthieu Moy]

----- Original Message -----
> Hi Peff,
> 
> On 2015-02-24 13:28, Jeff King wrote:
> > On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote:
> > 
> >> > Thanks! No rush, as we are not even accepted yet, but you can create a
> >> > profile at:
> >> >
> >> >   http://google-melange.com
> >> >
> >> > and ask to join the "git" project as a mentor.
> >>
> >> I guess I can only ask that after the org is accepted, I will do so
> >> when (and if) that is the case.
> > 
> > I think you can do it now; I had to create the project profile in order
> > to do the application. But again, no rush.
> 
> I tried, but there are no orgs listed as of yet when I click "Make
> connection".

Not sure what it's supposed to look like, but I think if you give us your username we can invite you as mentor.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Git for Windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re: [RFH] GSoC 2015 application

[Johannes Schindelin]

Hi Matthieu,

On 2015-02-25 11:25, Matthieu Moy wrote:
> ----- Original Message -----

>> On 2015-02-24 13:28, Jeff King wrote:
>> > On Tue, Feb 24, 2015 at 01:25:32PM +0100, Johannes Schindelin wrote:
>> >
>> >> > Thanks! No rush, as we are not even accepted yet, but you can create a
>> >> > profile at:
>> >> >
>> >> >   http://google-melange.com
>> >> >
>> >> > and ask to join the "git" project as a mentor.
>> >>
>> >> I guess I can only ask that after the org is accepted, I will do so
>> >> when (and if) that is the case.
>> >
>> > I think you can do it now; I had to create the project profile in order
>> > to do the application. But again, no rush.
>>
>> I tried, but there are no orgs listed as of yet when I click "Make
>> connection".
> 
> Not sure what it's supposed to look like, but I think if you give us
> your username we can invite you as mentor.

Thanks. My username is – surprise! – 'dscho' ;-)

Ciao,
Dscho

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Git for Windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re: [RFH] GSoC 2015 application

[Matthieu Moy]

Johannes Schindelin <johannes.schindelin@gmx.de> writes:

> After considerable consideration, I am offering to mentor
> Windows-related projects (into which I count conversion of scripts
> into builtins).

Good news!

About the proposal:

  The idea of this project is to dive into the Git source code and
  convert, say, git-add--interactive.perl and/or git stash into proper C
  code, making it a so-called "built-in".

My advice would be to try converting several small scripts, and avoid
targetting a big one. This way, you can have a first patch series
reviewed on-list, and merged in pu rather soon. From my experience, an
early review is very important to get the student on track, and
splitting the GSoC into multiple related projects avoids the situation
where you have the feature "95% completed" at the end of the GSoC, but
nothing merged.

add--interactive and stash are relatively complex beasts, perhaps
git-pull.sh would be easier to start with.

OTOH, you know which script would be most useful to be converted into a
builtin much better than me!

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Git for Windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re: [RFH] GSoC 2015 application

[Junio C Hamano]

On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> About the proposal:
>
>   The idea of this project is to dive into the Git source code and
>   convert, say, git-add--interactive.perl and/or git stash into proper C
>   code, making it a so-called "built-in".
>
> My advice would be to try converting several small scripts, and avoid
> targetting a big one....
> add--interactive and stash are relatively complex beasts, perhaps
> git-pull.sh would be easier to start with.

Yeah, I think that is a very good suggestion.

Also drop "proper" as if scripted Porcelains are second class citizens ;-)

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Git for Windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re: [RFH] GSoC 2015 application

[Johannes Schindelin]

Hi Junio,

On 2015-02-24 19:25, Junio C Hamano wrote:
> On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> About the proposal:
>>
>>   The idea of this project is to dive into the Git source code and
>>   convert, say, git-add--interactive.perl and/or git stash into proper C
>>   code, making it a so-called "built-in".
>>
>> My advice would be to try converting several small scripts, and avoid
>> targetting a big one....
>> add--interactive and stash are relatively complex beasts, perhaps
>> git-pull.sh would be easier to start with.
> 
> Yeah, I think that is a very good suggestion.

Well, git-pull.sh is really small. I did not want to give the impression that the Git project is giving out freebies. But I have no objection to change it if you open that PR.

> Also drop "proper" as if scripted Porcelains are second class citizens ;-)

If you had to deal with the portability/performance issues of the shell scripts I am frequently faced with, you would not call them first class citizens, either.

Ciao,
Dscho

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Git for Windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [RFH] GSoC 2015 application

[Junio C Hamano]

Johannes Schindelin <johannes.schindelin@gmx.de> writes:

>> Also drop "proper" as if scripted Porcelains are second class citizens ;-)
>
> If you had to deal with the portability/performance issues of the
> shell scripts I am frequently faced with, you would not call them
> first class citizens, either.

Perhaps that might be the case.

But I am polite enough to refrain from calling that "not a problem
on 'proper' platforms".  I expect the same courtesy from others ;-).

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Git for Windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re: [RFH] GSoC 2015 application

[Matthieu Moy]

Johannes Schindelin <johannes.schindelin@gmx.de> writes:

> Hi Junio,
>
> On 2015-02-24 19:25, Junio C Hamano wrote:
>> On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy
>> <Matthieu.Moy@grenoble-inp.fr> wrote:
>>> About the proposal:
>>>
>>>   The idea of this project is to dive into the Git source code and
>>>   convert, say, git-add--interactive.perl and/or git stash into proper C
>>>   code, making it a so-called "built-in".
>>>
>>> My advice would be to try converting several small scripts, and avoid
>>> targetting a big one....
>>> add--interactive and stash are relatively complex beasts, perhaps
>>> git-pull.sh would be easier to start with.
>> 
>> Yeah, I think that is a very good suggestion.
>
> Well, git-pull.sh is really small. I did not want to give the impression that the Git project is giving out freebies. But I have no objection to change it if you open that PR.

To get an idea, I counted the lines of code written by the student I
mentored last year:

$ git log --author tanayabh@gmail.com -p | diffstat -s   
 43 files changed, 1225 insertions(+), 367 deletions(-)

I would consider this GSoC as "average" (i.e. not exceptionnally good,
but certainly not a bad one either), so you may hope for more, but you
should not _expect_ much more IMHO.

In comparison:

$ wc -l git-add--interactive.perl
1654 git-add--interactive.perl
$ wc -l git-stash.sh
617 git-stash.sh

I'd expect a rewrite in C to at least double the number of lines of
code, so rewriting git-stash would mean writting at least as many lines
of code as the GSoC above. git-add--interactive.perl would be rather far
above.

But my point was not to convert _only_ git-pull.sh, but to have a GSoC
starting with this one and plan more. Then, depending on how it goes,
you can adjust the target.

This all depends on what you intend to do if the student does not finish
the job. If you're going to do the rewrite yourself anyway, then having
the student do even half of it is good already. If you're not going to
finish the job by yourself, then a 95%-done-rewrite means a piece of
code posted on the mailing list and never merged (and a lot of time
wasted).

In any case, these are just advices, certainly not objections or hard
requests to change.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Git for Windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Stefan Beller]

On Tue, Feb 24, 2015 at 3:56 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>
>> Hi Junio,
>>
>> On 2015-02-24 19:25, Junio C Hamano wrote:
>>> On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy
>>> <Matthieu.Moy@grenoble-inp.fr> wrote:
>>>> About the proposal:
>>>>
>>>>   The idea of this project is to dive into the Git source code and
>>>>   convert, say, git-add--interactive.perl and/or git stash into proper C
>>>>   code, making it a so-called "built-in".
>>>>
>>>> My advice would be to try converting several small scripts, and avoid
>>>> targetting a big one....
>>>> add--interactive and stash are relatively complex beasts, perhaps
>>>> git-pull.sh would be easier to start with.
>>>
>>> Yeah, I think that is a very good suggestion.
>>
>> Well, git-pull.sh is really small. I did not want to give the impression that the Git project is giving out freebies. But I have no objection to change it if you open that PR.
>
> To get an idea, I counted the lines of code written by the student I
> mentored last year:
>
> $ git log --author tanayabh@gmail.com -p | diffstat -s
>  43 files changed, 1225 insertions(+), 367 deletions(-)
>
> I would consider this GSoC as "average" (i.e. not exceptionnally good,
> but certainly not a bad one either), so you may hope for more, but you
> should not _expect_ much more IMHO.
>
> In comparison:
>
> $ wc -l git-add--interactive.perl
> 1654 git-add--interactive.perl
> $ wc -l git-stash.sh
> 617 git-stash.sh
>
> I'd expect a rewrite in C to at least double the number of lines of
> code, so rewriting git-stash would mean writting at least as many lines
> of code as the GSoC above. git-add--interactive.perl would be rather far
> above.
>
> But my point was not to convert _only_ git-pull.sh, but to have a GSoC
> starting with this one and plan more. Then, depending on how it goes,
> you can adjust the target.
>
> This all depends on what you intend to do if the student does not finish
> the job. If you're going to do the rewrite yourself anyway, then having
> the student do even half of it is good already. If you're not going to
> finish the job by yourself, then a 95%-done-rewrite means a piece of
> code posted on the mailing list and never merged (and a lot of time
> wasted).
>
> In any case, these are just advices, certainly not objections or hard
> requests to change.
>


Once upon a time (Sep 2013) I rewrote builtin/repack.c which was a
shell script before. I did not have much real-coding expertise with the
git community before and by today there are 403 lines of code in
builtin/repack.c. so going for roughly 3 times (1200 lines of code) change
would make a summer, specially if you need to learn how the workflow
is in the open source world.  There the lines in c doubled nearly exactly.
(before 197 shell lines, afterwards 387 c lines).

Just last weekend I met people, who were afraid of contributing to open source
"because sometimes the internet can be very mean". Git being quite a high
profile project, as it is widely used, might not help, but rather fear
people away.
That said I would not underestimate the initial time a student needs to learn
the workflow. Though most of that learning is done in the micro project phase.

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Michael J Gruber]

Stefan Beller venit, vidit, dixit 25.02.2015 01:34:
> On Tue, Feb 24, 2015 at 3:56 PM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>>
>>> Hi Junio,
>>>
>>> On 2015-02-24 19:25, Junio C Hamano wrote:
>>>> On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy
>>>> <Matthieu.Moy@grenoble-inp.fr> wrote:
>>>>> About the proposal:
>>>>>
>>>>>   The idea of this project is to dive into the Git source code and
>>>>>   convert, say, git-add--interactive.perl and/or git stash into proper C
>>>>>   code, making it a so-called "built-in".
>>>>>
>>>>> My advice would be to try converting several small scripts, and avoid
>>>>> targetting a big one....
>>>>> add--interactive and stash are relatively complex beasts, perhaps
>>>>> git-pull.sh would be easier to start with.
>>>>
>>>> Yeah, I think that is a very good suggestion.
>>>
>>> Well, git-pull.sh is really small. I did not want to give the impression that the Git project is giving out freebies. But I have no objection to change it if you open that PR.
>>
>> To get an idea, I counted the lines of code written by the student I
>> mentored last year:
>>
>> $ git log --author tanayabh@gmail.com -p | diffstat -s
>>  43 files changed, 1225 insertions(+), 367 deletions(-)
>>
>> I would consider this GSoC as "average" (i.e. not exceptionnally good,
>> but certainly not a bad one either), so you may hope for more, but you
>> should not _expect_ much more IMHO.
>>
>> In comparison:
>>
>> $ wc -l git-add--interactive.perl
>> 1654 git-add--interactive.perl
>> $ wc -l git-stash.sh
>> 617 git-stash.sh
>>
>> I'd expect a rewrite in C to at least double the number of lines of
>> code, so rewriting git-stash would mean writting at least as many lines
>> of code as the GSoC above. git-add--interactive.perl would be rather far
>> above.
>>
>> But my point was not to convert _only_ git-pull.sh, but to have a GSoC
>> starting with this one and plan more. Then, depending on how it goes,
>> you can adjust the target.
>>
>> This all depends on what you intend to do if the student does not finish
>> the job. If you're going to do the rewrite yourself anyway, then having
>> the student do even half of it is good already. If you're not going to
>> finish the job by yourself, then a 95%-done-rewrite means a piece of
>> code posted on the mailing list and never merged (and a lot of time
>> wasted).
>>
>> In any case, these are just advices, certainly not objections or hard
>> requests to change.
>>
> 
> 
> Once upon a time (Sep 2013) I rewrote builtin/repack.c which was a
> shell script before. I did not have much real-coding expertise with the
> git community before and by today there are 403 lines of code in
> builtin/repack.c. so going for roughly 3 times (1200 lines of code) change
> would make a summer, specially if you need to learn how the workflow
> is in the open source world.  There the lines in c doubled nearly exactly.
> (before 197 shell lines, afterwards 387 c lines).
> 
> Just last weekend I met people, who were afraid of contributing to open source
> "because sometimes the internet can be very mean". Git being quite a high
> profile project, as it is widely used, might not help, but rather fear
> people away.

I guess they've read about the lkml too much :)

I consider the gitml to be a relatively civilized place for constructive
criticism, without rants, flame wars and ad hominem swear word attacks.
I don't know how it's perceived from the outside (but that drew me in
back then).

Maybe we can attach a photo of our maintainer to the GSOC page? That
would prove we're nice and polite :)

> That said I would not underestimate the initial time a student needs to learn
> the workflow. Though most of that learning is done in the micro project phase.

Yes, the technical workflow as well as the "social habits". They should
follow the gitml even before, and then the micro projects are a great
learning ground.

Michael

Re: Re: [RFH] GSoC 2015 application

[Johannes Schindelin]

Hi Matthieu,

On 2015-02-25 00:56, Matthieu Moy wrote:
> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
> 
>> On 2015-02-24 19:25, Junio C Hamano wrote:
>>> On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy
>>> <Matthieu.Moy@grenoble-inp.fr> wrote:
>>>> About the proposal:
>>>>
>>>>   The idea of this project is to dive into the Git source code and
>>>>   convert, say, git-add--interactive.perl and/or git stash into proper C
>>>>   code, making it a so-called "built-in".
>>>>
>>>> My advice would be to try converting several small scripts, and avoid
>>>> targetting a big one....
>>>> add--interactive and stash are relatively complex beasts, perhaps
>>>> git-pull.sh would be easier to start with.
>>>
>>> Yeah, I think that is a very good suggestion.
>>
>> Well, git-pull.sh is really small. I did not want to give the impression that the Git project is giving out freebies. But I have no objection to change it if you open that PR.
> 
> To get an idea, I counted the lines of code written by the student I
> mentored last year:
> 
> $ git log --author tanayabh@gmail.com -p | diffstat -s   
>  43 files changed, 1225 insertions(+), 367 deletions(-)
> 
> I would consider this GSoC as "average" (i.e. not exceptionnally good,
> but certainly not a bad one either), so you may hope for more, but you
> should not _expect_ much more IMHO.
> 
> In comparison:
> 
> $ wc -l git-add--interactive.perl
> 1654 git-add--interactive.perl
> $ wc -l git-stash.sh
> 617 git-stash.sh
> 
> I'd expect a rewrite in C to at least double the number of lines of
> code, so rewriting git-stash would mean writting at least as many lines
> of code as the GSoC above. git-add--interactive.perl would be rather far
> above.

Sure. You're right, I was thinking too big.

> But my point was not to convert _only_ git-pull.sh, but to have a GSoC
> starting with this one and plan more. Then, depending on how it goes,
> you can adjust the target.

That's excellent advice.

> This all depends on what you intend to do if the student does not finish
> the job. If you're going to do the rewrite yourself anyway, then having
> the student do even half of it is good already. If you're not going to
> finish the job by yourself, then a 95%-done-rewrite means a piece of
> code posted on the mailing list and never merged (and a lot of time
> wasted).

Well, all of this is academic at this point. Let's see whether we get accepted, and then, if a student finds this project compelling enough.

If both things happen, I will definitely heed your advice and encourage the student to start with some script that is easily converted, to "get her feet wet".

Ciao,
Dscho

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Git for Windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [msysGit] Re: [RFH] GSoC 2015 application

[Christian Couder]

On Wed, Feb 25, 2015 at 9:44 AM, Johannes Schindelin
<johannes.schindelin@gmx.de> wrote:
> Hi Matthieu,
>
> On 2015-02-25 00:56, Matthieu Moy wrote:
>> Johannes Schindelin <johannes.schindelin@gmx.de> writes:
>>
>>> On 2015-02-24 19:25, Junio C Hamano wrote:
>>>> On Tue, Feb 24, 2015 at 9:32 AM, Matthieu Moy
>>>> <Matthieu.Moy@grenoble-inp.fr> wrote:
>>>>> About the proposal:
>>>>>
>>>>>   The idea of this project is to dive into the Git source code and
>>>>>   convert, say, git-add--interactive.perl and/or git stash into proper C
>>>>>   code, making it a so-called "built-in".
>>>>>
>>>>> My advice would be to try converting several small scripts, and avoid
>>>>> targetting a big one....
>>>>> add--interactive and stash are relatively complex beasts, perhaps
>>>>> git-pull.sh would be easier to start with.
>>>>
>>>> Yeah, I think that is a very good suggestion.
>>>
>>> Well, git-pull.sh is really small. I did not want to give the impression that the Git project is giving out freebies. But I have no objection to change it if you open that PR.
>>
>> To get an idea, I counted the lines of code written by the student I
>> mentored last year:
>>
>> $ git log --author tanayabh@gmail.com -p | diffstat -s
>>  43 files changed, 1225 insertions(+), 367 deletions(-)
>>
>> I would consider this GSoC as "average" (i.e. not exceptionnally good,
>> but certainly not a bad one either), so you may hope for more, but you
>> should not _expect_ much more IMHO.
>>
>> In comparison:
>>
>> $ wc -l git-add--interactive.perl
>> 1654 git-add--interactive.perl
>> $ wc -l git-stash.sh
>> 617 git-stash.sh

There is also:

$ wc -l git-bisect.sh
528 git-bisect.sh

And there is already builtin/bisect--helper.c that can be used to
convert step by step shell code to C. I can mentor or co-mentor this
convertion by the way, but that would conflict with the other bisect
related GSoC project if a student takes it.

>> I'd expect a rewrite in C to at least double the number of lines of
>> code, so rewriting git-stash would mean writting at least as many lines
>> of code as the GSoC above. git-add--interactive.perl would be rather far
>> above.
>
> Sure. You're right, I was thinking too big.
>
>> But my point was not to convert _only_ git-pull.sh, but to have a GSoC
>> starting with this one and plan more. Then, depending on how it goes,
>> you can adjust the target.
>
> That's excellent advice.

Yeah!

>> This all depends on what you intend to do if the student does not finish
>> the job. If you're going to do the rewrite yourself anyway, then having
>> the student do even half of it is good already. If you're not going to
>> finish the job by yourself, then a 95%-done-rewrite means a piece of
>> code posted on the mailing list and never merged (and a lot of time
>> wasted).
>
> Well, all of this is academic at this point.

Yeah, but it's still worth keeping in many parts of our collective mind :-)

> Let's see whether we get accepted, and then, if a student finds this project compelling enough.
>
> If both things happen, I will definitely heed your advice and encourage the student to start with some script that is easily converted, to "get her feet wet".

Great!

Thanks,
Christian.

Re: Re: [RFH] GSoC 2015 application

[Duy Nguyen]

On Wed, Feb 25, 2015 at 6:56 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> To get an idea, I counted the lines of code written by the student I
> mentored last year:
>
> $ git log --author tanayabh@gmail.com -p | diffstat -s
>  43 files changed, 1225 insertions(+), 367 deletions(-)
>
> I would consider this GSoC as "average" (i.e. not exceptionnally good,
> but certainly not a bad one either), so you may hope for more, but you
> should not _expect_ much more IMHO.
>
> In comparison:
>
> $ wc -l git-add--interactive.perl
> 1654 git-add--interactive.perl
> $ wc -l git-stash.sh
> 617 git-stash.sh
>
> I'd expect a rewrite in C to at least double the number of lines of
> code, so rewriting git-stash would mean writting at least as many lines
> of code as the GSoC above. git-add--interactive.perl would be rather far
> above.
>
> But my point was not to convert _only_ git-pull.sh, but to have a GSoC
> starting with this one and plan more. Then, depending on how it goes,
> you can adjust the target.

Some data point as I have a half-baked builtin/pull.c in my
(forgotten) private branch for 3 years. pull.c has 389 lines (with 24
shell lines left in "#if 0"). git-pull.sh has 340 lines. Let's add 100
C lines  to pull.c when it's complete, that's 50% more lines. But in
the git-pull case the student could get a good head start by reusing
my code, maybe.
-- 
Duy

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Git for Windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Re: [RFH] GSoC 2015 application

[Johannes Schindelin]

Hi Duy,

On 2015-02-25 11:02, Duy Nguyen wrote:
> On Wed, Feb 25, 2015 at 6:56 AM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> To get an idea, I counted the lines of code written by the student I
>> mentored last year:
>>
>> $ git log --author tanayabh@gmail.com -p | diffstat -s
>>  43 files changed, 1225 insertions(+), 367 deletions(-)
>>
>> I would consider this GSoC as "average" (i.e. not exceptionnally good,
>> but certainly not a bad one either), so you may hope for more, but you
>> should not _expect_ much more IMHO.
>>
>> In comparison:
>>
>> $ wc -l git-add--interactive.perl
>> 1654 git-add--interactive.perl
>> $ wc -l git-stash.sh
>> 617 git-stash.sh
>>
>> I'd expect a rewrite in C to at least double the number of lines of
>> code, so rewriting git-stash would mean writting at least as many lines
>> of code as the GSoC above. git-add--interactive.perl would be rather far
>> above.
>>
>> But my point was not to convert _only_ git-pull.sh, but to have a GSoC
>> starting with this one and plan more. Then, depending on how it goes,
>> you can adjust the target.
> 
> Some data point as I have a half-baked builtin/pull.c in my
> (forgotten) private branch for 3 years. pull.c has 389 lines (with 24
> shell lines left in "#if 0"). git-pull.sh has 340 lines. Let's add 100
> C lines  to pull.c when it's complete, that's 50% more lines. But in
> the git-pull case the student could get a good head start by reusing
> my code, maybe.

Thanks for the pointer, I will keep that in mind!

Ciao,
Dscho

-- 
-- 
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.

You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Git for Windows" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [RFH] GSoC 2015 application

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> and the list of microprojects:
>
>   http://git.github.io/SoC-2015-Microprojects.html

A few for micros.

diff --git a/SoC-2015-Microprojects.md b/SoC-2015-Microprojects.md
index b79a89f..f3b2b55 100644
--- a/SoC-2015-Microprojects.md
+++ b/SoC-2015-Microprojects.md
@@ -107,4 +107,25 @@ suitable.  Just remember to keep the change small!  It is much better
 for you to finish a small but complete change than to try something
 too ambitious and not get it done.
 
-**TODO** add entries
+### Make "git -C '' cmd" not to barf.
+
+Instead, make it just like "cd ''", which is a no-op that silently
+succeeds.  Cf. $gmane/258109
+
+### Allow "-" as a short-hand for "@{-1}" in more places.
+
+Pick one command that operates on branch names.  Teach it the "-"
+shorthand that stands for "the branch we were previously on", like we
+did for "git merge -" sometime after we introduced "git checkout -".
+Cf. $gmane/230828
+
+### Make "git diff --no-index $directory $file" DWIM better.
+
+"git diff --no-index $directory $directory/$file" is obviously what
+the user wanted.
+
+### Forbid "log --graph --no-walk"
+
+Because --graph is about connected history while --no-walk is about
+discrete points.  Cf. $gmane/216083
+

Re: [RFH] GSoC 2015 application

[Junio C Hamano]

On Wed, Feb 18, 2015 at 1:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> A few for micros.
>
> +### Allow "-" as a short-hand for "@{-1}" in more places.
> +
> +Pick one command that operates on branch names.  Teach it the "-"
> +shorthand that stands for "the branch we were previously on", like we

In the same vein (people may have noticed that "Pick one" is meant to
make this into multiple micros ;-)

### Use unsigned integral type for collection of bits.

Pick one field of a structure that (1) is of signed integral type and (2) is
used as a collection of multiple bits. Discuss if there is a good reason
why it has to be a signed integral field and change it to an unsigned
type otherwise.  Cf. $gmane/263751

Re: [RFH] GSoC 2015 application

[Matthieu Moy]

Jeff King <peff@peff.net> writes:

> I do need somebody to volunteer as backup admin. This doesn't need
> to involve any specific commitment, but is mostly about what to do if I
> get hit by a bus.

If you promise me to try hard not to be hit by a bus and no one else
steps in, I can be the backup admin.

> Where I really need help now is in the "ideas" page:
>
>   http://git.github.io/SoC-2015-Ideas.html

Throwing out a few ideas for discussion, I can write something if people
agree.

* "git bisect fixed/unfixed", to allow bisecting a fix instead of a
  regression less painfully. There were already some proposed patches
  ( https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_bisect_fix.2Funfixed ),
  so it shouldn't be too hard. Perhaps this item can be included in the
  "git bisect --first-parent" idea (turning it into "git bisect
  improvements").

* Be nicer to the user on tracked/untracked merge conflicts

  I've had it on
  https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#Be_nicer_to_the_user_on_tracked.2Funtracked_merge_conflicts
  for a while but never got someone to do it.

    "When merging a commit which has tracked files with the same name as local untracked files, Git refuses to proceed. It could be nice to:

    - Accept the situation without conflict when the tracked file has
      the exact same content as the local untracked file (which would
      become tracked). No data is lost, nothing can be committed
      accidentally.

    - Possibly, for fast-forward merges, if a local files belongs to the
      index but not to the last commit, attempt a merge between the
      upstream version and the local one (resulting in the same content
      as if the file had just been committed, but without introducing an
      extra commit). 

    Recent versions SVN do something similar: on update, it considers
    added but not committed files like normal tracked files, and
    attempts a merge of the upstream version with the local one (which
    always succeeds when the files have identical content). Attempting a
    merge for non-fast forward cases would probably not make sense: it
    would mix changes coming from the merge with other changes that do
    not come from a commit."
  
  This shouldn't be technically too hard, but finding which behavior is
  right, where should things be customizeable and what the default value
  for the configuration should be will probably lead to interesting
  discussions. It contains two steps, which is good (all-or-nothing
  projects are much harder to deal with). The biggest drawback is that
  the first item may be simple for a GSoC while the second could be both
  controversial and hard to implement (depending on which solution is
  taken).

> and the list of microprojects:
>
>   http://git.github.io/SoC-2015-Microprojects.html

Here are a few ideas, based on
https://git.wiki.kernel.org/index.php/SmallProjectsIdeas

-- >8 --
From 513774754872436ea8b7eea63828b804c6a107e7 Mon Sep 17 00:00:00 2001
From: Matthieu Moy <Matthieu.Moy@imag.fr>
Date: Thu, 19 Feb 2015 10:48:06 +0100
Subject: [PATCH] 2015 microproject ideas

---
 SoC-2015-Microprojects.md | 42 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 42 insertions(+)

diff --git a/SoC-2015-Microprojects.md b/SoC-2015-Microprojects.md
index 8cb6a8f..1abf595 100644
--- a/SoC-2015-Microprojects.md
+++ b/SoC-2015-Microprojects.md
@@ -128,3 +128,45 @@ the user wanted.
 
 Because --graph is about connected history while --no-walk is about
 discrete points.  Cf. $gmane/216083
+
+### Move ~/.git-credentials and ~/.git-credential-cache to ~/.config/git
+
+Most of git dotfiles can be located, at the user's option, in
+~/.<file> or in ~/.config/git/<file>, following the [XDG
+standard](http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html).
+~/.git-credentials and ~/.git-credential-cache are still hardcoded as
+~/.<file>, and should allow using the XDG directory layout too
+(~/.git-credentials could be allowed as ~/.config/git/credential and
+~/.git-credential-cache could be allowed as ~/.cache/git/credential,
+possibly modified by $XDG_CONFIG_HOME and $XDG_CACHE_HOME).
+
+Each of these files can be a microproject of its own. The suggested
+approach is:
+
+* See how XDG was implemented for other files (run "git log --grep
+  XDG" in Git's source code) and read the XDG specification.
+
+* Implement and test the new behavior, without breaking compatibility
+  with the old behavior.
+
+* Update the documentation
+
+### Add configuration options for some commonly used command-line options
+
+This includes:
+
+* git am -3
+
+* git am -c
+
+Some people always run the command with these options, and would
+prefer to be able to activate them by default in ~/.gitconfig.
+
+### Add more builtin patterns for userdiff
+
+"git diff" shows the function name corresponding to each hunk after
+the @@ ... @@ line. For common languages (C, HTML, Ada, Matlab, ...),
+the way to find the function name is built-in Git's source code as
+regular expressions (see userdiff.c). A few languages are common
+enough to deserve a built-in driver, but are not yet recognized. For
+example, CSS, shell.
-- 
2.0.2.737.gfb43bde



-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [RFH] GSoC 2015 application

[Jeff King]

On Thu, Feb 19, 2015 at 11:32:46AM +0100, Matthieu Moy wrote:

> > I do need somebody to volunteer as backup admin. This doesn't need
> > to involve any specific commitment, but is mostly about what to do if I
> > get hit by a bus.
> 
> If you promise me to try hard not to be hit by a bus and no one else
> steps in, I can be the backup admin.

Thanks. I need you to register and create a profile at:

  https://www.google-melange.com/gsoc/homepage/google/gsoc2015

and tell me your username (the information from last year does not carry
forward automatically). Then I mark you as backup admin and (I think)
you have to then accept.

> Throwing out a few ideas for discussion, I can write something if people
> agree.
> 
> * "git bisect fixed/unfixed", to allow bisecting a fix instead of a
>   regression less painfully. There were already some proposed patches
>   ( https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_bisect_fix.2Funfixed ),
>   so it shouldn't be too hard. Perhaps this item can be included in the
>   "git bisect --first-parent" idea (turning it into "git bisect
>   improvements").

That seems like a reasonable topic. I was about to say "but it's much
more complicated than fix/unfixed..." but it looks like that wiki entry
covers the past discussion (and reading and understanding that would be
a first step for the student). I agree it's probably smaller than a
full-summer project and can get lumped into the other bisect idea.

> * Be nicer to the user on tracked/untracked merge conflicts
> [...]

Sounds OK to me, though I agree the merging of untracked files is a
little controversial. There are also a lot of corner cases in
merge-recursive, and I think still some documented cases where we can
overwrite untracked files. Maybe a more encompassing project would be to
organize and dig into some of those corner cases.

>  SoC-2015-Microprojects.md | 42 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 42 insertions(+)

Thanks, applied, although...

> +### Move ~/.git-credentials and ~/.git-credential-cache to ~/.config/git
> +
> +Most of git dotfiles can be located, at the user's option, in
> +~/.<file> or in ~/.config/git/<file>, following the [XDG
> +standard](http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html).
> +~/.git-credentials and ~/.git-credential-cache are still hardcoded as
> +~/.<file>, and should allow using the XDG directory layout too
> +(~/.git-credentials could be allowed as ~/.config/git/credential and
> +~/.git-credential-cache could be allowed as ~/.cache/git/credential,
> +possibly modified by $XDG_CONFIG_HOME and $XDG_CACHE_HOME).
> +
> +Each of these files can be a microproject of its own. The suggested
> +approach is:
> +
> +* See how XDG was implemented for other files (run "git log --grep
> +  XDG" in Git's source code) and read the XDG specification.
> +
> +* Implement and test the new behavior, without breaking compatibility
> +  with the old behavior.
> +
> +* Update the documentation

I think these might be getting a little larger than "micro". That's OK
if the student can handle it, but we may want to mark them as such. I'll
leave it for now, though, as we have a bit more breathing room on the
microprojects.

> +### Add configuration options for some commonly used command-line options
> +
> +This includes:
> +
> +* git am -3
> +
> +* git am -c
> +
> +Some people always run the command with these options, and would
> +prefer to be able to activate them by default in ~/.gitconfig.

The direction here seems reasonable, though I think we have
mailinfo.scissors already, so "-c" may not be a good example.

> +### Add more builtin patterns for userdiff
> +
> +"git diff" shows the function name corresponding to each hunk after
> +the @@ ... @@ line. For common languages (C, HTML, Ada, Matlab, ...),
> +the way to find the function name is built-in Git's source code as
> +regular expressions (see userdiff.c). A few languages are common
> +enough to deserve a built-in driver, but are not yet recognized. For
> +example, CSS, shell.

I am not sure that understanding the horrible regexes involved in some
userdiff counts as "micro", but OK. :)

-Peff

Re: [RFH] GSoC 2015 application

[Matthieu Moy]

Jeff King <peff@peff.net> writes:

>> * Be nicer to the user on tracked/untracked merge conflicts
>> [...]
>
> Sounds OK to me, though I agree the merging of untracked files is a
> little controversial.

Yes. To me, part of the project is to identify cases where this is
actually not controversial (OTOH, it's a bit frustrating when I do a
trivial pull and Git complains because I already have the file).

>> +### Move ~/.git-credentials and ~/.git-credential-cache to ~/.config/git
>> +
>> +Most of git dotfiles can be located, at the user's option, in
>> +~/.<file> or in ~/.config/git/<file>, following the [XDG
>> +standard](http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html).
>> +~/.git-credentials and ~/.git-credential-cache are still hardcoded as
>> +~/.<file>, and should allow using the XDG directory layout too
>> +(~/.git-credentials could be allowed as ~/.config/git/credential and
>> +~/.git-credential-cache could be allowed as ~/.cache/git/credential,
>> +possibly modified by $XDG_CONFIG_HOME and $XDG_CACHE_HOME).
>> +
>> +Each of these files can be a microproject of its own. The suggested
>> +approach is:
>> +
>> +* See how XDG was implemented for other files (run "git log --grep
>> +  XDG" in Git's source code) and read the XDG specification.
>> +
>> +* Implement and test the new behavior, without breaking compatibility
>> +  with the old behavior.
>> +
>> +* Update the documentation
>
> I think these might be getting a little larger than "micro".

The ~/.git-credential-cache may be a bit harder, but the case of
~/.git-credentials should follow the same pattern as files for which
this is already done. So, doing it by mimicking existing code shouldn't
be too hard.

But maybe that's me being optimistic ;-).

>> +### Add configuration options for some commonly used command-line options
>> +
>> +This includes:
>> +
>> +* git am -3
>> +
>> +* git am -c
>> +
>> +Some people always run the command with these options, and would
>> +prefer to be able to activate them by default in ~/.gitconfig.
>
> The direction here seems reasonable, though I think we have
> mailinfo.scissors already, so "-c" may not be a good example.

Ah, indeed. The documentation makes it a bit hard to find, but I'll send
a patch.

>> +### Add more builtin patterns for userdiff
>> +
>> +"git diff" shows the function name corresponding to each hunk after
>> +the @@ ... @@ line. For common languages (C, HTML, Ada, Matlab, ...),
>> +the way to find the function name is built-in Git's source code as
>> +regular expressions (see userdiff.c). A few languages are common
>> +enough to deserve a built-in driver, but are not yet recognized. For
>> +example, CSS, shell.
>
> I am not sure that understanding the horrible regexes involved in some
> userdiff counts as "micro", but OK. :)

I agree the regexes are horrible, but here also the project is not about
doing something really new, but reproducing what has already been done
for others.

At least, students not fluent with regular expressions have a pointer to
userdiff.c and can quickly see that the microproject is not meant for
them ;-).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [RFH] GSoC 2015 application

[Dennis Kaarsemaker]

On vr, 2015-02-20 at 11:06 +0100, Matthieu Moy wrote:
> The ~/.git-credential-cache may be a bit harder, but the case of
> ~/.git-credentials should follow the same pattern as files for which
> this is already done. So, doing it by mimicking existing code
> shouldn't
> be too hard.
> 
> But maybe that's me being optimistic ;-)

Having just copied that logic to one of my tools, I reaclly would have
fount if useful to have something that, given a config file name tells
you where it should be, maybe in the resident kitchen-sink that is
rev-parse:

$ git rev-parse --config git
/home/dennis/.gitconfig
$ git rev-parse --config gitk
/home/dennis/.gitk
$ git rev-parse --config foobar
/home/dennis/.foobar

Or, when XDG config files are used:

$ git rev-parse --config gitk
/home/dennis/.config/git/gitk
$ git rev-parse --config git
/home/dennis/.config/git/config
$ git rev-parse --config foobar
/home/dennis/.config/git/foobar

So, ~/.$filename or $XDG_CONFIG_HOME/git/filename, with a special case
only for git itself, with consistent selection of which to use
(currently gitk and git are inconsistent).

-- 
Dennis Kaarsemaker
http://www.kaarsemaker.net

Re: [RFH] GSoC 2015 application

[Matthieu Moy]

Dennis Kaarsemaker <dennis@kaarsemaker.net> writes:

> given a config file name tells
> you where it should be, maybe in the resident kitchen-sink that is
> rev-parse:

It's actually a bit harder than this, since when both XDG and ~/.<file>
exist, we read from both but write to one only. So there's not just one
answer to the question.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [RFH] GSoC 2015 application

[Eric Sunshine]

On Fri, Feb 20, 2015 at 5:06 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Jeff King <peff@peff.net> writes:
>> I think these might be getting a little larger than "micro".
>
> The ~/.git-credential-cache may be a bit harder, but the case of
> ~/.git-credentials should follow the same pattern as files for which
> this is already done. So, doing it by mimicking existing code shouldn't
> be too hard.
>
> But maybe that's me being optimistic ;-).

As a person who did a significant number of GSoC 2014 micro-project
reviews (as well as many actual GSoC reviews), I probably ought to
weigh in and say that this may be too optimistic. In fact, most of the
GSoC 2015 micro-project suggestions[1] seem far too large and
involved.

For 2014, most of the GSoC micro-projects were extremely simple, of
the form "replace starts_with() with skip_prefix()", yet most
applicants still required three or four (or more) attempts to get it
right (and some never did), even with extremely detailed hand-holding
reviews at each step. (And, such reviews are quite time-consuming. I
was allocating six to eight hours each day to those reviews, yet I
couldn't keep up with all the submissions.)

Although quite simple, many of the 2014 micro-projects[2]
(particularly from Michael Haggerty) had a bit of a twist (or trick
question) thrown in, requiring a tad more thought and effort than mere
mechanical search-and-replace. That was useful because it helped
identify potentially acceptable candidates more easily, however, that
added twist was probably a good upper limit on difficulty for
micro-projects.

Another important aspect of 2014's micro-projects was that they could
be accomplished with only very localized knowledge: that is, a student
could read the logic of the one function being touched and learn
enough to be successful. The micro-projects did not require global
knowledge of Git internals or hours of research.

The attitude in 2014 was that it was important for students to get a
taste of what it is like working on the Git project and what would be
expected of them as submitters, and for GSoC administrators and
mentors to get a feel for the applicants by how they interacted with
reviewers. By going through the review process on a project with high
engineering standards, it also was hope that students would learn and
benefit from the experience even if not selected. Extremely simple
micro-projects (possibly with a twist) in the style of 2014's were
more than sufficient to satisfy these goals, and were more than enough
to consume significant reviewer time. The suggested 2015's
micro-projects seem far in excess.

[1]: http://git.github.io/SoC-2015-Microprojects.html
[2]: http://git.github.io/SoC-2014-Microprojects.html

[PATCH 1/3] microprojects: tweaks after discussion with Peff

[Matthieu Moy]

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
 SoC-2015-Microprojects.md | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/SoC-2015-Microprojects.md b/SoC-2015-Microprojects.md
index e49cb07..c6123bb 100644
--- a/SoC-2015-Microprojects.md
+++ b/SoC-2015-Microprojects.md
@@ -158,14 +158,16 @@ approach is:
 
 * Update the documentation
 
+Even though the amount of code to write is small, these projects
+involve a lot of prior work to understand the specification and deal
+with all potential corner-cases.
+
 ### Add configuration options for some commonly used command-line options
 
 This includes:
 
 * git am -3
 
-* git am -c
-
 Some people always run the command with these options, and would
 prefer to be able to activate them by default in ~/.gitconfig.
 
@@ -177,3 +179,5 @@ the way to find the function name is built-in Git's source code as
 regular expressions (see userdiff.c). A few languages are common
 enough to deserve a built-in driver, but are not yet recognized. For
 example, CSS, shell.
+
+This project requires a very good knowledge of regular expressions.
-- 
2.3.0.157.g79e124b

[PATCH 2/3] GSoC ideas: git bisect fixed/unfixed

[Matthieu Moy]

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
 SoC-2015-Ideas.md | 45 ++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/SoC-2015-Ideas.md b/SoC-2015-Ideas.md
index a3e988e..4641800 100644
--- a/SoC-2015-Ideas.md
+++ b/SoC-2015-Ideas.md
@@ -34,7 +34,9 @@ should be honored without checking the ownership.  Cf. $gmane/243628
 Takes eol attributes into account to correct lossage/addition of CR at
 the end of line, with updates to "am".  Cf. $gmane/257445
 
-### "git bisect --first-parent".
+### git bisect improvements
+
+#### "git bisect --first-parent".
 
 When your project is strictly "new features are merged into trunk,
 never the other way around", it is handy to be able to first find
@@ -42,6 +44,47 @@ a merge on the trunk that merged a topic to point fingers at when
 a bug appears, instead of having to drill down to the individual
 commit on the faulty side branch.
 
+#### "git bisect fixed/unfixed"
+
+"git bisect" is initially meant to find regressions (i.e. the new code
+is bad, and the old one used to work). The opposite may happen too:
+look for the commit which fixed a bug. It is already possible using
+"git bisect", but the user has to type "good" to mean "the bug is
+there" and "bad" to mean "the bug is fixed", which isn't convenient.
+
+It would be nice to allow the user to explicitely say "git bisect
+fixed" and "git bisect unfixed" instead. It is actually much harder
+than defining "fixed"/"unfixed" as aliases for "bad"/"good".
+
+A patch for this feature was sent to the mailing list in this thread a
+few years ago by Dscho:
+http://thread.gmane.org/gmane.comp.version-control.git/86063
+
+Unfortunately there were some problems with the patch and no one tried
+to fix them. So the same problem/suggestion is often reported on the
+mailing list, for example:
+
+    http://thread.gmane.org/gmane.comp.version-control.git/165141
+    http://thread.gmane.org/gmane.comp.version-control.git/170113
+    http://thread.gmane.org/gmane.comp.version-control.git/182398 
+
+A patch series to let "old/new" be used instead of "good/bad" was
+started here:
+
+http://thread.gmane.org/gmane.comp.version-control.git/199758/focus=199869
+
+There is still work to be done to complete it.
+
+Note than another feature with the name "git bisect fix" was suggested
+to do something else:
+
+http://thread.gmane.org/gmane.comp.version-control.git/169026
+
+Since there have already been discussions and patches, the remaining
+work is probably less than a GSoC, so this project should be grouped
+with another one (like git bisect --first-parent) to make a full GSoC
+proposal.
+
 ### Unifying `git branch -l`, `git tag -l`, and `git for-each-ref`
 
 These three commands are all about selecting a subset of a repository's
-- 
2.3.0.157.g79e124b

[PATCH 3/3] idea: Be nicer to the user on tracked/untracked merge conflicts

[Matthieu Moy]

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
 SoC-2015-Ideas.md | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/SoC-2015-Ideas.md b/SoC-2015-Ideas.md
index 4641800..86de476 100644
--- a/SoC-2015-Ideas.md
+++ b/SoC-2015-Ideas.md
@@ -117,3 +117,30 @@ Cf. $gmane/213180 $gmane/212950
 ### Introduce threading to checkout codepath, possibly helping Windows folks.
 
 Cf. $gmane/235874
+
+### Be nicer to the user on tracked/untracked merge conflicts
+
+When merging a commit which has tracked files with the same name as
+local untracked files, Git refuses to proceed. It could be nice to:
+
+ - Accept the situation without conflict when the tracked file has the
+   exact same content as the local untracked file (which would become
+   tracked). No data is lost, nothing can be committed accidentally.
+
+ - Possibly, for fast-forward merges, if a local files belongs to the
+   index but not to the last commit, attempt a merge between the
+   upstream version and the local one (resulting in the same content
+   as if the file had just been committed, but without introducing an
+   extra commit).
+
+Recent versions SVN do something similar: on update, it considers
+added but not committed files like normal tracked files, and attempts
+a merge of the upstream version with the local one (which always
+succeeds when the files have identical content). Attempting a merge
+for non-fast forward cases would probably not make sense: it would mix
+changes coming from the merge with other changes that do not come from
+a commit.
+
+One difficulty with this project is to identify uncontroversial cases
+(where Git should merge without complaining) and all the possible
+corner-cases.
-- 
2.3.0.157.g79e124b

Re: [RFH] GSoC 2015 application

[Duy Nguyen]

On Thu, Feb 19, 2015 at 2:14 AM, Jeff King <peff@peff.net> wrote:
> and the list of microprojects:
>
>   http://git.github.io/SoC-2015-Microprojects.html
>

There is debian bug 777690 [1] that's basically about making tag's
version sort aware about -rc, -pre suffixes. I imagine it would touch
versioncmp.c and builtin/tag.c (to retrieve the suffixes from config
file).

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777690
-- 
Duy

Re: [RFH] GSoC 2015 application

[Jeff King]

On Fri, Feb 20, 2015 at 10:26:15AM +0700, Duy Nguyen wrote:

> On Thu, Feb 19, 2015 at 2:14 AM, Jeff King <peff@peff.net> wrote:
> > and the list of microprojects:
> >
> >   http://git.github.io/SoC-2015-Microprojects.html
> >
> 
> There is debian bug 777690 [1] that's basically about making tag's
> version sort aware about -rc, -pre suffixes. I imagine it would touch
> versioncmp.c and builtin/tag.c (to retrieve the suffixes from config
> file).
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777690

I think that's a reasonable thing to work on, but it's too big for a
microproject and too small for a GSoC.

I think this could be an "extra credit" for the project to unify
for-each-ref, "tag -l", and "branch -l", though. That will vastly
enhance the supporting abilities the latter two (e.g., you could sort by
taggerdate).

-Peff

Re: [RFH] GSoC 2015 application

[Junio C Hamano]

On Thu, Feb 19, 2015 at 11:13 PM, Jeff King <peff@peff.net> wrote:

>> There is debian bug 777690 [1] that's basically about making tag's
>> version sort aware about -rc, -pre suffixes. I imagine it would touch
>> versioncmp.c and builtin/tag.c (to retrieve the suffixes from config
>> file).
>>
>> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777690
>
> I think that's a reasonable thing to work on, but it's too big for a
> microproject and too small for a GSoC.

That is certainly too big as a Micro, but I do not think it is too small
for GSoC, if it is to be done right (meaning, not just implementing an
arbitrary version comparison hardwired, but design how to make it
extensible).

I have a feeling that I am complaining that student projects are
designed to be too grand and getting told that I am overly pessimistic
by everybody else every year. Perhaps this year others may prove
me wrong, if we can find mentors, that is ;-)

Support customized reordering in version sort

[Duy Nguyen]

On Fri, Feb 20, 2015 at 12:26:29AM -0800, Junio C Hamano wrote:
> On Thu, Feb 19, 2015 at 11:13 PM, Jeff King <peff@peff.net> wrote:
> 
> >> There is debian bug 777690 [1] that's basically about making tag's
> >> version sort aware about -rc, -pre suffixes. I imagine it would touch
> >> versioncmp.c and builtin/tag.c (to retrieve the suffixes from config
> >> file).
> >>
> >> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777690
> >
> > I think that's a reasonable thing to work on, but it's too big for a
> > microproject and too small for a GSoC.
> 
> That is certainly too big as a Micro, but I do not think it is too small
> for GSoC, if it is to be done right (meaning, not just implementing an
> arbitrary version comparison hardwired, but design how to make it
> extensible).

I did write "maybe more of mini-size than micro" then looked at the
micro list again and somehow decided to delete that. Anyway while I
still have my attention on it, might as well do it.

My idea is to make it easy for the user to change the sort algorithm.
And it's probably intuitive to just substitute a string with
something. So if "1-rc1" is put incorrectly before "1.1" and you
realize that "1.999" ought to be the last one before "2". You could
tell git to internally replace "1-rc1" with "1.999".

This patch does that. The user feeds substitution rules via
versionsort.substitute config keys, e.g.

    git config versionsort.substitute "-rc .999"

Performance is not a concern because I don't think people would throw
100k tags to it. There are two issues I'm aware of but not addressed:

 - the order of substitution matters, but right now it's up in the air
 - case-sensitiveness may surprise users

-- 8< --
diff --git a/versioncmp.c b/versioncmp.c
index 7511e08..2419e38 100644
--- a/versioncmp.c
+++ b/versioncmp.c
@@ -1,4 +1,5 @@
 #include "cache.h"
+#include "strbuf.h"
 
 /*
  * versioncmp(): copied from string/strverscmp.c in glibc commit
@@ -20,6 +21,57 @@
 #define  CMP    2
 #define  LEN    3
 
+struct subst_rule
+{
+	const char *before;
+	const char *after;
+};
+static struct subst_rule *rules;
+static int rule_nr, rule_alloc;
+
+static int versioncmp_config(const char *k, const char *v, void *cb)
+{
+	char *p, *s;
+	if (strcmp(k, "versionsort.substitute"))
+		return 0;
+	ALLOC_GROW(rules, rule_nr + 1, rule_alloc);
+	s = xstrdup(v);
+	p = strchr(s, ' ');
+	if (!p)
+		return error("missing space in %s", v);
+	*p = '\0';
+	rules[rule_nr].before = s;
+	rules[rule_nr].after = p + 1;
+	rule_nr++;
+	return 0;
+}
+
+static char *substitute(const unsigned char **strp)
+{
+	struct strbuf sb = STRBUF_INIT;
+	const char *str = (const char *)*strp;
+	int i;
+	if (!rules) {
+		rules = xmalloc(sizeof(*rules));
+		rule_alloc = 1;
+		git_config(versioncmp_config, NULL);
+	}
+	for (i = 0; i < rule_nr; i++) {
+		const struct subst_rule *r = rules + i;
+		const char *p = strstr(str, r->before);
+		if (!p)
+			continue;
+		if (!sb.len)
+			strbuf_addstr(&sb, str);
+		strbuf_splice(&sb, p - str, strlen(r->before),
+			      r->after, strlen(r->after));
+		str = sb.buf;
+	}
+	if ((const unsigned char *)str == *strp)
+		return NULL;
+	*strp = (const unsigned char *)sb.buf;
+	return sb.buf;
+}
 
 /*
  * Compare S1 and S2 as strings holding indices/version numbers,
@@ -32,6 +84,7 @@ int versioncmp(const char *s1, const char *s2)
 {
 	const unsigned char *p1 = (const unsigned char *) s1;
 	const unsigned char *p2 = (const unsigned char *) s2;
+	char *free1, *free2;
 	unsigned char c1, c2;
 	int state, diff;
 
@@ -58,6 +111,8 @@ int versioncmp(const char *s1, const char *s2)
 
 	if (p1 == p2)
 		return 0;
+	free1 = substitute(&p1);
+	free2 = substitute(&p2);
 
 	c1 = *p1++;
 	c2 = *p2++;
@@ -75,6 +130,10 @@ int versioncmp(const char *s1, const char *s2)
 	}
 
 	state = result_type[state * 3 + (((c2 == '0') + (isdigit (c2) != 0)))];
+	if (state != LEN) {
+		free(free1);
+		free(free2);
+	}
 
 	switch (state) {
 	case CMP:
@@ -82,10 +141,16 @@ int versioncmp(const char *s1, const char *s2)
 
 	case LEN:
 		while (isdigit (*p1++))
-			if (!isdigit (*p2++))
+			if (!isdigit (*p2++)) {
+				free(free1);
+				free(free2);
 				return 1;
+			}
 
-		return isdigit (*p2) ? -1 : diff;
+		c2 = *p2;
+		free(free1);
+		free(free2);
+		return isdigit (c2) ? -1 : diff;
 
 	default:
 		return state;
-- 8< --

Re: Support customized reordering in version sort

[Junio C Hamano]

On Fri, Feb 20, 2015 at 7:02 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>
> My idea is to make it easy for the user to change the sort algorithm.
> And it's probably intuitive to just substitute a string with
> something. So if "1-rc1" is put incorrectly before "1.1" and you
> realize that "1.999" ought to be the last one before "2". You could
> tell git to internally replace "1-rc1" with "1.999".
>
> This patch does that. The user feeds substitution rules via
> versionsort.substitute config keys, e.g.
>
>     git config versionsort.substitute "-rc .999"

I would say 1-rc1 comes and then 1-rc2 and then 1-rc3 ... 1-rc10 and then
1-rc11 and then finally 1. It will probably be followed by 1.1-rc1, 1.1-rc2, ...
and then 1.1 (aka 1.1-final).

If 1-rc1 is equated with 1.9991 because -rc is replaced with .999, how does
it make 1 come after 1.99911, and 1.1.9992 come before 1.1?

I didn't read the patch text and perhaps the explanation above is the only
thing faulty about your message, or perhaps my reading is faulty and the
above describes a sound idea, but I do not see how the above makes sense.

Re: Support customized reordering in version sort

[Duy Nguyen]

On Sat, Feb 21, 2015 at 10:25 AM, Junio C Hamano <gitster@pobox.com> wrote:
> On Fri, Feb 20, 2015 at 7:02 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>>
>> My idea is to make it easy for the user to change the sort algorithm.
>> And it's probably intuitive to just substitute a string with
>> something. So if "1-rc1" is put incorrectly before "1.1" and you
>> realize that "1.999" ought to be the last one before "2". You could
>> tell git to internally replace "1-rc1" with "1.999".
>>
>> This patch does that. The user feeds substitution rules via
>> versionsort.substitute config keys, e.g.
>>
>>     git config versionsort.substitute "-rc .999"
>
> I would say 1-rc1 comes and then 1-rc2 and then 1-rc3 ... 1-rc10 and then
> 1-rc11 and then finally 1. It will probably be followed by 1.1-rc1, 1.1-rc2, ...
> and then 1.1 (aka 1.1-final).
>
> If 1-rc1 is equated with 1.9991 because -rc is replaced with .999, how does
> it make 1 come after 1.99911, and 1.1.9992 come before 1.1?
>
> I didn't read the patch text and perhaps the explanation above is the only
> thing faulty about your message, or perhaps my reading is faulty and the
> above describes a sound idea, but I do not see how the above makes sense.

No, faulty thinking. Back to the whiteboard..

-- 
Duy

Re: Support customized reordering in version sort

[Junio C Hamano]

On Fri, Feb 20, 2015 at 7:33 PM, Duy Nguyen <pclouds@gmail.com> wrote:
> On Sat, Feb 21, 2015 at 10:25 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> On Fri, Feb 20, 2015 at 7:02 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>>>
>>> My idea is to make it easy for the user to change the sort algorithm.
>>> And it's probably intuitive to just substitute a string with
>>> something. So if "1-rc1" is put incorrectly before "1.1" and you
>>> realize that "1.999" ought to be the last one before "2". You could
>>> tell git to internally replace "1-rc1" with "1.999".
>>>
>>> This patch does that. The user feeds substitution rules via
>>> versionsort.substitute config keys, e.g.
>>>
>>>     git config versionsort.substitute "-rc .999"
>>
>> I would say 1-rc1 comes and then 1-rc2 and then 1-rc3 ... 1-rc10 and then
>> 1-rc11 and then finally 1. It will probably be followed by 1.1-rc1, 1.1-rc2, ...
>> and then 1.1 (aka 1.1-final).
>>
>> If 1-rc1 is equated with 1.9991 because -rc is replaced with .999, how does
>> it make 1 come after 1.99911, and 1.1.9992 come before 1.1?
>>
>> I didn't read the patch text and perhaps the explanation above is the only
>> thing faulty about your message, or perhaps my reading is faulty and the
>> above describes a sound idea, but I do not see how the above makes sense.
>
> No, faulty thinking. Back to the whiteboard..

One version of vercmp() I read went like this:

 (1) Chomp the version strings into an alternate runs of digits and
non-digits. e.g. 1.2.13 becomes
      "1", ".", "2", "." and "13" while 1.2.9 becomes "1", ".", "2",
"." and "9".
 (2) Compare corresponding elements with strcmp() for runs of
non-digits, and numerically for
      runs of digits. In the above example, up to the shared "1.2."
would compare equal, and the
      final run of digits, "13" and "9" are compared numerically and
we declare that 1.2.13 comes
      later.

I think you can add a twist by introducing "optionally this can
appear" substring. When there is
such an optional substring defined, you also define if the side that
lack the optional substring
comes before or after the side that has one. For example, you declare
"[-]rc" as "optional
substring that makes the owner of such a substring sort before others"
(call it "optional negative
substring") and comparing 2.0-rc12, 2.0-rc2 and 2.0:

 - "2.0" becomes "2", ".", "0" and "2.0-rc2" becomes "2", ".", "0",
"-rc", "2". Comparing them
   from left to right, the first difference is "lack of anything (2.0
side runs out tokens)" and
   "-rc", which is marked as optional negative. Hence 2.0-rc2 sorts before 2.0

 - "2.0-rc12" and "2.0-rc2" splits into tokens similarly. The first
difference you see will be
   after you match "-rc" and "-rc", which is "12" vs "2". Comparing
them numerically, you
   know "2.0-rc12" comes later.

You can define values to optional negatives and optional positives to
express a more
elaborate sort order e.g.

  1.0-pre12 < 1.0-rc0 < 1.0 < 1.0-post1

even though "-post" does not have to be declared as optional positive.

Re: Support customized reordering in version sort

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> You can define values to optional negatives and optional positives to
> express a more
> elaborate sort order e.g.
>
>   1.0-pre12 < 1.0-rc0 < 1.0 < 1.0-post1
>
> even though "-post" does not have to be declared as optional positive.

... that is, you say "-pre" is a more negative optional than "-rc"
that is also a negative optional.

[PATCH] versionsort: support reorder prerelease suffixes

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 Second round. Looking better. We can do
 "1.0-pre12 < 1.0-rc0 < 1.0 < 1.0-post1" too but it relies on
 config key's loading order, a bit iffy.

 Documentation/config.txt |  7 +++++++
 t/t7004-tag.sh           | 28 +++++++++++++++++++++++++++
 versioncmp.c             | 50 ++++++++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 85 insertions(+)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 04e2a71..8e078df 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2539,6 +2539,13 @@ user.signingkey::
 	This option is passed unchanged to gpg's --local-user parameter,
 	so you may specify a key using any method that gpg supports.
 
+versionsort.prereleaseSuffix::
+	When version sort is used in linkgit:git-tag[1], prerelease
+	tags (e.g. "1.0-rc1") may appear after the main release
+	"1.0". By specifying the suffix "-rc" in this variable,
+	"1.0-rc1" will appear before "1.0". One variable assignment
+	per suffix.
+
 web.browser::
 	Specify a web browser that may be used by some commands.
 	Currently only linkgit:git-instaweb[1] and linkgit:git-help[1]
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index 35c805a..8bfeef9 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -1459,6 +1459,34 @@ test_expect_success 'invalid sort parameter in configuratoin' '
 	test_cmp expect actual
 '
 
+test_expect_success 'version sort with prerelease reordering' '
+	git config --unset tag.sort &&
+	git config versionsort.prereleaseSuffix -rc &&
+	git tag foo1.6-rc1 &&
+	git tag foo1.6-rc2 &&
+	git tag -l --sort=version:refname "foo*" >actual &&
+	cat >expect <<-\EOF &&
+	foo1.3
+	foo1.6-rc1
+	foo1.6-rc2
+	foo1.6
+	foo1.10
+	EOF
+	test_cmp expect actual
+'
+
+test_expect_success 'reverse version sort with prerelease reordering' '
+	git tag -l --sort=-version:refname "foo*" >actual &&
+	cat >expect <<-\EOF &&
+	foo1.10
+	foo1.6
+	foo1.6-rc2
+	foo1.6-rc1
+	foo1.3
+	EOF
+	test_cmp expect actual
+'
+
 run_with_limited_stack () {
 	(ulimit -s 128 && "$@")
 }
diff --git a/versioncmp.c b/versioncmp.c
index 7511e08..80bfd10 100644
--- a/versioncmp.c
+++ b/versioncmp.c
@@ -1,4 +1,5 @@
 #include "cache.h"
+#include "string-list.h"
 
 /*
  * versioncmp(): copied from string/strverscmp.c in glibc commit
@@ -20,6 +21,48 @@
 #define  CMP    2
 #define  LEN    3
 
+static const struct string_list *prereleases;
+static int initialized;
+
+/*
+ * p1 and p2 point to the first different character in two strings. If
+ * either p1 or p2 starts with a prerelease suffix, it will be forced
+ * to be on top.
+ *
+ * If both p1 and p2 start with (different) suffix, the order is
+ * determined by config file.
+ *
+ * Note that we don't have to deal with the situation when both p1 and
+ * p2 start with the same suffix because the common part is already
+ * consumed by the caller.
+ *
+ * Return non-zero if *diff contains the return value for versioncmp()
+ */
+static int swap_prereleases(const void *p1_,
+			    const void *p2_,
+			    int *diff)
+{
+	const char *p1 = p1_;
+	const char *p2 = p2_;
+	int i, i1 = -1, i2 = -1;
+
+	for (i = 0; i < prereleases->nr; i++) {
+		const char *suffix = prereleases->items[i].string;
+		if (i1 == -1 && starts_with(p1, suffix))
+			i1 = i;
+		if (i2 == -1 && starts_with(p2, suffix))
+			i2 = i;
+	}
+	if (i1 == -1 && i2 == -1)
+		return 0;
+	if (i1 >= 0 && i2 >= 0)
+		*diff = i1 - i2;
+	else if (i1 >= 0)
+		*diff = -1;
+	else /* if (i2 >= 0) */
+		*diff = 1;
+	return 1;
+}
 
 /*
  * Compare S1 and S2 as strings holding indices/version numbers,
@@ -74,6 +117,13 @@ int versioncmp(const char *s1, const char *s2)
 		state += (c1 == '0') + (isdigit (c1) != 0);
 	}
 
+	if (!initialized) {
+		initialized = 1;
+		prereleases = git_config_get_value_multi("versionsort.prereleasesuffix");
+	}
+	if (prereleases && swap_prereleases(p1 - 1, p2 - 1, &diff))
+		return diff;
+
 	state = result_type[state * 3 + (((c2 == '0') + (isdigit (c2) != 0)))];
 
 	switch (state) {
-- 
2.3.0.rc1.137.g477eb31

Re: [PATCH] versionsort: support reorder prerelease suffixes

[Junio C Hamano]

Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:

> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
>  Second round. Looking better. We can do
>  "1.0-pre12 < 1.0-rc0 < 1.0 < 1.0-post1" too but it relies on
>  config key's loading order, a bit iffy.
>
>  Documentation/config.txt |  7 +++++++
>  t/t7004-tag.sh           | 28 +++++++++++++++++++++++++++
>  versioncmp.c             | 50 ++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 85 insertions(+)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index 04e2a71..8e078df 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -2539,6 +2539,13 @@ user.signingkey::
>  	This option is passed unchanged to gpg's --local-user parameter,
>  	so you may specify a key using any method that gpg supports.
>  
> +versionsort.prereleaseSuffix::
> +	When version sort is used in linkgit:git-tag[1], prerelease
> +	tags (e.g. "1.0-rc1") may appear after the main release
> +	"1.0". By specifying the suffix "-rc" in this variable,
> +	"1.0-rc1" will appear before "1.0". One variable assignment
> +	per suffix.

I think the last half-sentence want to mean that

	[versionsort]
                prereleaseSuffix = -pre
        	prereleaseSuffix = -rc

is the supported way to write, and not

	[versionsort]
        	prereleaseSuffix = -pre -rc

but it probably is unclear unless the reader already knows what it
is trying to say.  The reader also needs to learn somewhere how the
order of the entries affects the result.

> +	if (i1 == -1 && i2 == -1)
> +		return 0;
> +	if (i1 >= 0 && i2 >= 0)
> +		*diff = i1 - i2;
> +	else if (i1 >= 0)
> +		*diff = -1;

p1 is a prerelease and p2 is not, so p1 comes before p2.

> +	else /* if (i2 >= 0) */
> +		*diff = 1;

and the other way around.

The math makes sense, I think.

Re: [PATCH] versionsort: support reorder prerelease suffixes

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

>> +versionsort.prereleaseSuffix::
>> +	When version sort is used in linkgit:git-tag[1], prerelease
>> +	tags (e.g. "1.0-rc1") may appear after the main release
>> +	"1.0". By specifying the suffix "-rc" in this variable,
>> +	"1.0-rc1" will appear before "1.0". One variable assignment
>> +	per suffix.
>
> I think the last half-sentence want to mean that
>
> 	[versionsort]
>                 prereleaseSuffix = -pre
>         	prereleaseSuffix = -rc
>
> is the supported way to write, and not
>
> 	[versionsort]
>         	prereleaseSuffix = -pre -rc
>
> but it probably is unclear unless the reader already knows what it
> is trying to say.  The reader also needs to learn somewhere how the
> order of the entries affects the result.

This is already in 'next', so could you fix that half-sentence in
the documentation via an incremental update?

Thanks.

Re: [PATCH] versionsort: support reorder prerelease suffixes

[Duy Nguyen]

On Thu, Mar 5, 2015 at 8:28 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>>> +versionsort.prereleaseSuffix::
>>> +    When version sort is used in linkgit:git-tag[1], prerelease
>>> +    tags (e.g. "1.0-rc1") may appear after the main release
>>> +    "1.0". By specifying the suffix "-rc" in this variable,
>>> +    "1.0-rc1" will appear before "1.0". One variable assignment
>>> +    per suffix.
>>
>> I think the last half-sentence want to mean that
>>
>>       [versionsort]
>>                 prereleaseSuffix = -pre
>>               prereleaseSuffix = -rc
>>
>> is the supported way to write, and not
>>
>>       [versionsort]
>>               prereleaseSuffix = -pre -rc
>>
>> but it probably is unclear unless the reader already knows what it
>> is trying to say.  The reader also needs to learn somewhere how the
>> order of the entries affects the result.
>
> This is already in 'next', so could you fix that half-sentence in
> the documentation via an incremental update?

How about..

".. "1.0-rc1" will appear before "1.0".  This key can be specified
multiple times, one for each suffix. The order of suffixes in the
config file determines the sorting order (e.g. if "-pre" appears
before "-rc" in the config file then 1.0-preXX is sorted before
1.0-rcXX). The sorting order between different suffixes is undefined
if they are in multiple config files"
-- 
Duy

Re: [PATCH] versionsort: support reorder prerelease suffixes

[Junio C Hamano]

Duy Nguyen <pclouds@gmail.com> writes:

> On Thu, Mar 5, 2015 at 8:28 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>>> +versionsort.prereleaseSuffix::
>>>> +    When version sort is used in linkgit:git-tag[1], prerelease
>>>> +    tags (e.g. "1.0-rc1") may appear after the main release
>>>> +    "1.0". By specifying the suffix "-rc" in this variable,
>>>> +    "1.0-rc1" will appear before "1.0". One variable assignment
>>>> +    per suffix.
> ...
> How about..
>
> ".. "1.0-rc1" will appear before "1.0".  This key can be specified
> multiple times, one for each suffix. The order of suffixes in the
> config file determines the sorting order (e.g. if "-pre" appears
> before "-rc" in the config file then 1.0-preXX is sorted before
> 1.0-rcXX). The sorting order between different suffixes is undefined
> if they are in multiple config files"

OK. Later we might resurrect that "How would we spell 'reset this
variable' in our configuration file? Is that even a good idea in
the first place?" topic and at that time the last sentence may have
to change to make it more useful, but because we are not there yet,
the above would be a reasonable description.

Re: [PATCH] versionsort: support reorder prerelease suffixes

[Eric Sunshine]

On Tue, Mar 10, 2015 at 3:52 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Duy Nguyen <pclouds@gmail.com> writes:
>> How about..
>>
>> ".. "1.0-rc1" will appear before "1.0".  This key can be specified
>> multiple times, one for each suffix. The order of suffixes in the

Minor bike-shedding: s/one for each suffix/once per suffix/

>> config file determines the sorting order (e.g. if "-pre" appears
>> before "-rc" in the config file then 1.0-preXX is sorted before
>> 1.0-rcXX). The sorting order between different suffixes is undefined
>> if they are in multiple config files"
>
> OK. Later we might resurrect that "How would we spell 'reset this
> variable' in our configuration file? Is that even a good idea in
> the first place?" topic and at that time the last sentence may have
> to change to make it more useful, but because we are not there yet,
> the above would be a reasonable description.

[PATCH] config.txt: update versioncmp.prereleaseSuffix

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 Documentation/config.txt | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/Documentation/config.txt b/Documentation/config.txt
index 69a7345..fe8705d 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2527,8 +2527,13 @@ versionsort.prereleaseSuffix::
 	When version sort is used in linkgit:git-tag[1], prerelease
 	tags (e.g. "1.0-rc1") may appear after the main release
 	"1.0". By specifying the suffix "-rc" in this variable,
-	"1.0-rc1" will appear before "1.0". One variable assignment
-	per suffix.
+	"1.0-rc1" will appear before "1.0".
++
+This variable can be specified multiple times, once per suffix. The
+order of suffixes in the config file determines the sorting order
+(e.g. if "-pre" appears before "-rc" in the config file then 1.0-preXX
+is sorted before 1.0-rcXX). The sorting order between different
+suffixes is undefined if they are in multiple config files.
 
 web.browser::
 	Specify a web browser that may be used by some commands.
-- 
2.3.0.rc1.137.g477eb31

Re: [RFH] GSoC 2015 application

[Michael Haggerty]

On 02/18/2015 08:14 PM, Jeff King wrote:
> The response to my previous email was not overwhelming, but people did
> express some interest in Git doing GSoC this year. So I've started on
> the application, using last year's version as a template.

Regretfully, I can't in good conscience volunteer to be a GSoC mentor
this year. I have too many other projects going on and don't see how I
can free up enough time to be a good mentor.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu

Re: [RFH] GSoC 2015 application

[Jeff King]

On Fri, Feb 20, 2015 at 06:35:09AM +0100, Michael Haggerty wrote:

> On 02/18/2015 08:14 PM, Jeff King wrote:
> > The response to my previous email was not overwhelming, but people did
> > express some interest in Git doing GSoC this year. So I've started on
> > the application, using last year's version as a template.
> 
> Regretfully, I can't in good conscience volunteer to be a GSoC mentor
> this year. I have too many other projects going on and don't see how I
> can free up enough time to be a good mentor.

Thanks for letting us know. I am somewhat in the same boat. I might be
able to make time, but the bar that the student/project combo would have
to clear would be quite high for me to agree to do so.

This brings up an important issue. We cannot do GSoC without mentors. I
had hoped that people populating the "ideas" list would volunteer to
mentor for their projects.

But so far the possibilities are:

  - Stefan

  - me, who has already promised to be stingy

  - Matthieu, who also cited time constraints

  - Junio, who contributed some project ideas, but who in the past has
    declined to mentor in order to remain impartial as the maintainer
    who evaluates student results (which I think is quite reasonable)

So...basically 1 mentor and 2 reticent maybes? That doesn't look good.
We are not committed to anything until we accept student proposals,
of course. But I would not want to waste students' time in applying if
it is not realistic for us to accept them.

-Peff

Re: [RFH] GSoC 2015 application

[Junio C Hamano]

On Thu, Feb 19, 2015 at 11:29 PM, Jeff King <peff@peff.net> wrote:
>
> This brings up an important issue. We cannot do GSoC without mentors. I
> had hoped that people populating the "ideas" list would volunteer to
> mentor for their projects.
>
> But so far the possibilities are:
>
>   - Stefan
>
>   - me, who has already promised to be stingy
>
>   - Matthieu, who also cited time constraints
>
>   - Junio, who contributed some project ideas, but who in the past has
>     declined to mentor in order to remain impartial as the maintainer
>     who evaluates student results (which I think is quite reasonable)
>
> So...basically 1 mentor and 2 reticent maybes? That doesn't look good.

Indeed, the mentor panel looks particularly weak this year, if nobody
can afford the time for proper mentoring.

Even though I can indirectly help by giving reviews at a more hand-holding
level than usual, there is a limit. And I definitely do not foresee acting as a
mentor myself.

Re: [RFH] GSoC 2015 application

[Matthieu Moy]

Jeff King <peff@peff.net> writes:

>   - Matthieu, who also cited time constraints

Just to clarify: last year we were co-mentoring with Ram. I ended up
having a lot of time and did most of the work (not blaming Ram, and I
enjoyed the experience). I'm still motivated to co-mentor, but this time
the co-mentoring has to be more balanced (or unballanced to the other
mentor ;-) ).

>   - Junio, who contributed some project ideas, but who in the past has
>     declined to mentor in order to remain impartial as the maintainer
>     who evaluates student results (which I think is quite reasonable)

Yes, as a mentor I did appreciate having Junio as impartial
maintainer/reviewer. And he did for sure contribute even without being a
mentor!

>From your list, it seems we can target 1 or 2 slots. I'd say it's still
worth applying, but if we don't find more mentors then perhaps it would
make sense to say so explicitely in
http://git.github.io/SoC-2015-Ideas.html so that students looking for
organization know that we'll have very few slots.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [RFH] GSoC 2015 application

[Jeff King]

On Fri, Feb 20, 2015 at 10:39:42AM +0100, Matthieu Moy wrote:

> Jeff King <peff@peff.net> writes:
> 
> >   - Matthieu, who also cited time constraints
> 
> Just to clarify: last year we were co-mentoring with Ram. I ended up
> having a lot of time and did most of the work (not blaming Ram, and I
> enjoyed the experience). I'm still motivated to co-mentor, but this time
> the co-mentoring has to be more balanced (or unballanced to the other
> mentor ;-) ).

Yes, but who is your co-mentor this year? :)

> From your list, it seems we can target 1 or 2 slots. I'd say it's still
> worth applying, but if we don't find more mentors then perhaps it would
> make sense to say so explicitely in
> http://git.github.io/SoC-2015-Ideas.html so that students looking for
> organization know that we'll have very few slots.

I don't mind doing 1 slot if that's what we have resources for. But if
we have to say "eh, we do not really have enough mentors to support
you", then I wonder if it is worth doing.  They do not know how many
people have applied, or how tight the competition is.

-Peff

Re: [RFH] GSoC 2015 application

[Jeff King]

On Fri, Feb 20, 2015 at 04:48:44AM -0500, Jeff King wrote:

> > From your list, it seems we can target 1 or 2 slots. I'd say it's still
> > worth applying, but if we don't find more mentors then perhaps it would
> > make sense to say so explicitely in
> > http://git.github.io/SoC-2015-Ideas.html so that students looking for
> > organization know that we'll have very few slots.
> 
> I don't mind doing 1 slot if that's what we have resources for. But if
> we have to say "eh, we do not really have enough mentors to support
> you", then I wonder if it is worth doing.  They do not know how many
> people have applied, or how tight the competition is.

So that being said, I did complete the application. We can still
withdraw if we want before students start applying, or we can put a
disclaimer on the ideas page.

I tweaked the application text to update it for this year, but nothing
too major. The result is at:

  http://git.github.io/SoC-2015-Org-Application.html

That content was cut-and-pasted into Google's application interface.
Matthieu, as backup admin you should have access to tweak that if there
are typos, etc (and I will probably not be available to apply fixes from
now until the deadline, so please do so if you see anything).

We can continue to improve the ideas page as time goes on. At some point
Google will look at as part of the application, but probably not right
at the deadline. :)

-Peff

Re: [RFH] GSoC 2015 application

[Matthieu Moy]

Jeff King <peff@peff.net> writes:

> So that being said, I did complete the application. We can still
> withdraw if we want before students start applying, or we can put a
> disclaimer on the ideas page.

I'm in favor of the disclaimer, but I won't fight if other people think
it's better to just withdraw.

> That content was cut-and-pasted into Google's application interface.
> Matthieu, as backup admin you should have access to tweak that if there
> are typos, etc (and I will probably not be available to apply fixes from
> now until the deadline, so please do so if you see anything).

I do have access to the text here:

  http://www.google-melange.com/gsoc/org/survey_response/show/google/gsoc2015/git

but I did not find an "edit" button. I can edit

  http://www.google-melange.com/gsoc/org/profile/edit/google/gsoc2015/git

OTOH.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: [RFH] GSoC 2015 application

[Jeff King]

On Mon, Feb 23, 2015 at 09:02:58AM +0100, Matthieu Moy wrote:

> > That content was cut-and-pasted into Google's application interface.
> > Matthieu, as backup admin you should have access to tweak that if there
> > are typos, etc (and I will probably not be available to apply fixes from
> > now until the deadline, so please do so if you see anything).
> 
> I do have access to the text here:
> 
>   http://www.google-melange.com/gsoc/org/survey_response/show/google/gsoc2015/git
> 
> but I did not find an "edit" button. I can edit
> 
>   http://www.google-melange.com/gsoc/org/profile/edit/google/gsoc2015/git
> 
> OTOH.

I think it's just because the application period has ended, so our
answers to the questions are frozen.

-Peff

Re: [RFH] GSoC 2015 application

[Philip Oakley]

From: "Matthieu Moy" <Matthieu.Moy@grenoble-inp.fr>
Sent: Friday, February 20, 2015 9:39 AM
> Jeff King <peff@peff.net> writes:
>
>>   - Matthieu, who also cited time constraints
>
> Just to clarify: last year we were co-mentoring with Ram. I ended up
> having a lot of time and did most of the work (not blaming Ram, and I
> enjoyed the experience). I'm still motivated to co-mentor, but this 
> time
> the co-mentoring has to be more balanced (or unballanced to the other
> mentor ;-) ).
>
>>   - Junio, who contributed some project ideas, but who in the past 
>> has
>>     declined to mentor in order to remain impartial as the maintainer
>>     who evaluates student results (which I think is quite reasonable)
>
> Yes, as a mentor I did appreciate having Junio as impartial
> maintainer/reviewer. And he did for sure contribute even without being 
> a
> mentor!
>
> From your list, it seems we can target 1 or 2 slots. I'd say it's 
> still
> worth applying, but if we don't find more mentors then perhaps it 
> would
> make sense to say so explicitely in
> http://git.github.io/SoC-2015-Ideas.html so that students looking for
> organization know that we'll have very few slots.
>
> -- 
Hi,
Given the mention of the GSoC ideas list, I thought it worth writing out 
one of my little ideas..


A possible idea is to add a date based variant of shallow clone :

  'git clone --date <when> ...'

in the same vein as the existing depth (shallow) clone.

On the wire advertise a 'shallow-date' capability, passing a signed big 
integer as the unix time for the shallow cut-off point (i.e. future 
extensible to cover a very wide date range), with optional(?) date+depth 
hysteresis (clock skew) parameters.

Command line interface to use existing date/time formats, (and possibly 
revision dates?).

Extend 'git fetch' to include the --date <when> option.

Ensure that 'git push' continues to work with and between 
shallow/shallow-date clones.

Update the documentation in line with the capability.

Document any migration plan (if required)

Why
===

This capability would eliminate the existing confusion over the --depth 
parameter as different branches may require different depths to reach a 
"common" start point.

Extra points for an easy method of '--unshallow-date <new_when>' to 
remove 'old' commits that the user may no longer need locally. 
(unshallow may not be the right term...)

--
Philip

Re: [RFH] GSoC 2015 application

[Stefan Beller]

On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley <philipoakley@iee.org> wrote:

> A possible idea is to add a date based variant of shallow clone :
>
>  'git clone --date <when> ...'
>
> in the same vein as the existing depth (shallow) clone.

As food for thought:
Maybe broaden this further up to the git-ish way of describing refs, so

    git clone --since 2.weeks.ago <url>
    git clone --since v2.10 <url>
    git clone --since c0ffee^^ <url>

would all equally work?

I am not sure if that is feasible though, but it would come in handy. (E.g.
you are an end user and want to bisect down a bug which you notice in the
new version X but not in old version Y, so you start on getting the sources,
compiling, bisecting)

Re: [RFH] GSoC 2015 application

[Philip Oakley]

From: "Stefan Beller" <sbeller@google.com>
> On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley <philipoakley@iee.org> 
> wrote:
>
>> A possible idea is to add a date based variant of shallow clone :
>>
>>  'git clone --date <when> ...'
>>
>> in the same vein as the existing depth (shallow) clone.
>
> As food for thought:
> Maybe broaden this further up to the git-ish way of describing refs, 
> so
>
>    git clone --since 2.weeks.ago <url>
>    git clone --since v2.10 <url>
>    git clone --since c0ffee^^ <url>
>
> would all equally work?

The use of --since instead of --date would be an equally valid way of 
spelling the option (coders choice;-)

At the clone stage, the local Git can't determine (for the 2nd & 3d 
option) where such a revison is located, so would have to send the 
revision string to the server for processing, which could complicate the 
protocol. Hence my choice of a simple unix time value at the protocol 
level.

An alternate/addition is to use a nominated sha1 (from ls-remote) as a 
stand in for a date, allowing your option 2 (--since <tag>) to be 
implemented as an alias or script.

It all depends on how complicated we want it to become, but starting 
simple (though extensible) is important.

>
> I am not sure if that is feasible though, but it would come in handy. 
> (E.g.
> you are an end user and want to bisect down a bug which you notice in 
> the
> new version X but not in old version Y, so you start on getting the 
> sources,
> compiling, bisecting)
> --
Philip 

Re: [RFH] GSoC 2015 application

[Junio C Hamano]

On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley <philipoakley@iee.org> wrote:
>>
>>    git clone --since 2.weeks.ago <url>
>>    git clone --since v2.10 <url>
>
> The use of --since instead of --date would be an equally valid way of
> spelling the option (coders choice;-)

I think it is a demonstration of poor taste. Everywhere else, --since
is a way to
specify the date, not a revision. Why should this one alone should be different?

Re: [RFH] GSoC 2015 application

[Stefan Beller]

On Wed, Mar 4, 2015 at 4:22 PM, Junio C Hamano <gitster@pobox.com> wrote:
> On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley <philipoakley@iee.org> wrote:
>>>
>>>    git clone --since 2.weeks.ago <url>
>>>    git clone --since v2.10 <url>
>>
>> The use of --since instead of --date would be an equally valid way of
>> spelling the option (coders choice;-)
>
> I think it is a demonstration of poor taste. Everywhere else, --since
> is a way to
> specify the date, not a revision. Why should this one alone should be different?

I wanted to point out the broader use case than being stylish correct,
though from
an English grammars point of view `--since` should also be able to
describe a point
in time ("since 2 weeks ago" is as valid as "since Feb 17th")

I cannot remember the usual option off hand to describe the revision
instead of a date.
Maybe we want to have one option long term to allow any kind of input (revision
and date), as this may be easier to remember, especially if it aligns well with
the English language.

Re: [RFH] GSoC 2015 application

[Junio C Hamano]

Stefan Beller <sbeller@google.com> writes:

> On Wed, Mar 4, 2015 at 4:22 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley <philipoakley@iee.org> wrote:
>>>>
>>>>    git clone --since 2.weeks.ago <url>
>>>>    git clone --since v2.10 <url>
>>>
>>> The use of --since instead of --date would be an equally valid way of
>>> spelling the option (coders choice;-)
>>
>> I think it is a demonstration of poor taste. Everywhere else,
>> --since is a way to specify the date, not a revision. Why should
>> this one alone should be different?
>
> I wanted to point out the broader use case than being stylish correct,

OK.

I actually think it is OK to envision that "--since" will be made
appliable to non-dates in the longer term.  The proposal, when dug
into minor detail, may include extending approxidate() to take a
revision name, i.e.

	git log --since=v2.0.0 master

would behave as if

	git log --since=@1401300269 master

because that is the timestamp the v2.0.0 tag carries.

Note that I do not think it is a good idea to rewrite the above to 

	git log v2.0.0..master

at all (hint: think how you would rewrite --until).

As to the shallow-boundary capability implementation, I think what
has been discussed in the thread is basically sound.  Just send the
end-user supplied string ("2.weeks.ago", "v2.10", etc.) over the
wire without interpreting locally, and have the server end apply (an
updated) approxidate() on it, internally compute the exact cut-point
just like "git bundle create" does when it computes the prerequisites,
and use the resulting commits as the shallow boundary.

Re: [RFH] GSoC 2015 application

[Junio C Hamano]

Stefan Beller <sbeller@google.com> writes:

> I cannot remember the usual option off hand to describe the revision
> instead of a date.

Because "log --since=<date of v1.0> master" and "log v1.0..master"
mean two completely different things, we need some way to specify
which one of these two the user wants to "git clone" so that the
user can say at what point the user wants the shallow history to
begin.

I think it is a good idea to use --since for date-based cut-off, in
addition to the existing --depth that is depth-based cut-off, and we
probably would want another one that gives the topology-based
cut-off, so that we can express the range in a similar way to "log
v1.0..master".

But when we talk about the topology-based cut-off locally, we always
use the set syntax A..B, ^A B, etc. and never a command line option
with an argument to specify "the bottom of the history".  It is not
surprising that you don't remember any usual option for that,
because there isn't one.

The closest thing I can think of that looks somewhat like a command
line option is "--not", as in

    git log A B --not C D E

that is equivalent to "A B ^C ^D ^E", but that is not an option that
takes an argument.  I do not know if it is particularly a good idea
to say:

    git clone --not v2.0 $URL

to specify topology-based cut-off.

But we would need some way to say a set-based cut-off; I do not
think using --since for that purpose is a good idea, though, because
that is already taken for date-based cut-off, and mixing them
together will introduce confusion.

Re: [RFH] GSoC 2015 application

[Duy Nguyen]

On Wed, Mar 04, 2015 at 10:19:16PM -0800, Junio C Hamano wrote:
> But we would need some way to say a set-based cut-off; I do not
> think using --since for that purpose is a good idea, though, because
> that is already taken for date-based cut-off, and mixing them
> together will introduce confusion.

I agree. Although I look at this from the implementation perspective:
mixing the two would make it really hard to detect which is which.
Speaking of implementation..

On Thu, Mar 5, 2015 at 5:28 PM, Nguyễn Thái Ngọc Duy <pclouds@gmail.com> wrote:
> I do have plenty of topics to finish up. But I wanted to see how this
> feature would look like. I needed to write some code for that and for
> straightening my thoughts. Totally untested, but I think it looks cool :)
>
> I think this feature is feasible. The protocol and UI are still up in
> the air. Plenty of work for any student who wants to pick this up.

I think students are losing the chance to have this fun now. A rough
implementation is available at

    https://github.com/pclouds/git/tree/shallow-since

if anybody wants to try out. I don't post it here yet because while it
seems to be working in my limited tests, there could be some corner
cases to sort out, bugs and style violations. Also tests to be added.

Documentation changes below. --not and --since can be mixed. Neither
of them can be used with --depth though, but I'd consider it a
temporary limitation.

diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index b09a783..ec68374 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -13,6 +13,15 @@
 	to the specified number of commits from the tip of each remote
 	branch history. Tags for the deepened commits are not fetched.
 
+--since=<date>::
+	Deepen or shorten the history of a 'shallow' repository to
+	include all reachable commits that are after <date>.
+
+--not=<revision>::
+	Deepen or shorten the history of a 'shallow' repository to
+	exclude commits reachable from a specified remote branch or tag.
+	This option can be specified multiple times.
+
 --unshallow::
 	If the source repository is complete, convert a shallow
 	repository to a complete one, removing all the limitations
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index f1f2a3f..fc094c6 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -187,6 +187,14 @@ objects from the source repository into a pack in the cloned repository.
 	Create a 'shallow' clone with a history truncated to the
 	specified number of revisions.
 
+--since=<date>::
+	Create a 'shallow' clone with a history after the specified time.
+
+--not=<revision>::
+	Create a 'shallow' clone with a history, excluding commits
+	reachable from a specified remote branch or tag.  This option
+	can be specified multiple times.
+
 --[no-]single-branch::
 	Clone only the history leading to the tip of a single branch,
 	either specified by the `--branch` option or the primary
diff --git a/Documentation/technical/protocol-capabilities.txt b/Documentation/technical/protocol-capabilities.txt
index 4f8a7bf..3649301 100644
--- a/Documentation/technical/protocol-capabilities.txt
+++ b/Documentation/technical/protocol-capabilities.txt
@@ -179,6 +179,24 @@ This capability adds "deepen", "shallow" and "unshallow" commands to
 the  fetch-pack/upload-pack protocol so clients can request shallow
 clones.
 
+deepen-since
+------------
+
+This capability adds "deepen-since" command to fetch-pack/upload-pack
+protocol so the client can request shallow clones that are cut at a
+specific time, instead of depth. Internally it's equivalent of doing
+"rev-list --since=<time>" on the server side. "deepen-since" cannot be
+used with "deepen".
+
+deepen-not
+----------
+
+This capability adds "deepen-not" command to fetch-pack/upload-pack
+protocol so the client can request shallow clones that are cut at a
+specific revision, instead of depth. Internally it's equivalent of
+doing "rev-list --not <rev>" on the server side. "deepen-not"
+cannot be used with "deepen", but can be used with "deepen-since".
+
 no-progress
 -----------

Re: [RFH] GSoC 2015 application

[Duy Nguyen]

On Thu, Mar 5, 2015 at 6:55 AM, Stefan Beller <sbeller@google.com> wrote:
> On Wed, Mar 4, 2015 at 2:05 PM, Philip Oakley <philipoakley@iee.org> wrote:
>
>> A possible idea is to add a date based variant of shallow clone :
>>
>>  'git clone --date <when> ...'
>>
>> in the same vein as the existing depth (shallow) clone.
>
> As food for thought:
> Maybe broaden this further up to the git-ish way of describing refs, so
>
>     git clone --since 2.weeks.ago <url>
>     git clone --since v2.10 <url>
>     git clone --since c0ffee^^ <url>
>
> would all equally work?

Yes, and we could generalize it further: add shallow-rev-list
capability and send "shallow-rev-list <rev-list options and _some_
rev>" line to define shallow boundary. The protocol change would be
simple enough. The hard part is select a safe subset of rev-list
options that can be used in this mode and reject the rest.

> I am not sure if that is feasible though, but it would come in handy. (E.g.
> you are an end user and want to bisect down a bug which you notice in the
> new version X but not in old version Y, so you start on getting the sources,
> compiling, bisecting)
-- 
Duy

Re: [RFH] GSoC 2015 application

[Nguyễn Thái Ngọc Duy]

On Thu, Mar 5, 2015 at 5:05 AM, Philip Oakley <philipoakley@iee.org> wrote:
> Given the mention of the GSoC ideas list, I thought it worth writing out one
> of my little ideas..
>
>
> A possible idea is to add a date based variant of shallow clone :
>
>  'git clone --date <when> ...'
>
> in the same vein as the existing depth (shallow) clone.

I do have plenty of topics to finish up. But I wanted to see how this
feature would look like. I needed to write some code for that and for
straightening my thoughts. Totally untested, but I think it looks cool :)

I think this feature is feasible. The protocol and UI are still up in
the air. Plenty of work for any student who wants to pick this up.

Nguyễn Thái Ngọc Duy (6):
  upload-pack: move shallow deepen code out of receive_needs()
  upload-pack: move "shallow" sending code out of deepen()
  upload-pack: remove unused variable "backup"
  upload-pack: move "unshallow" sending code out of deepen()
  shallow.c: implement a generic shallow boundary finder based on rev-list
  upload-pack: example code to use get_shallow_commits_by_rev_list

 commit.h      |   2 +
 shallow.c     |  65 +++++++++++++++++++++++++++++
 upload-pack.c | 129 +++++++++++++++++++++++++++++++++++++---------------------
 3 files changed, 149 insertions(+), 47 deletions(-)

-- 
2.3.0.rc1.137.g477eb31

[PATCH 1/6] upload-pack: move shallow deepen code out of receive_needs()

[Nguyễn Thái Ngọc Duy]

This is a prep step for further refactoring. Besides reindentation and
s/shallows\./shallows->/g, no other changes are expected.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 upload-pack.c | 99 +++++++++++++++++++++++++++++++----------------------------
 1 file changed, 52 insertions(+), 47 deletions(-)

diff --git a/upload-pack.c b/upload-pack.c
index b531a32..74f48f9 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -531,6 +531,55 @@ error:
 	}
 }
 
+static void deepen(int depth, const struct object_array *shallows)
+{
+	struct commit_list *result = NULL, *backup = NULL;
+	int i;
+	if (depth == INFINITE_DEPTH && !is_repository_shallow())
+		for (i = 0; i < shallows->nr; i++) {
+			struct object *object = shallows->objects[i].item;
+			object->flags |= NOT_SHALLOW;
+		}
+	else
+		backup = result =
+			get_shallow_commits(&want_obj, depth,
+					    SHALLOW, NOT_SHALLOW);
+	while (result) {
+		struct object *object = &result->item->object;
+		if (!(object->flags & (CLIENT_SHALLOW|NOT_SHALLOW))) {
+			packet_write(1, "shallow %s",
+				     sha1_to_hex(object->sha1));
+			register_shallow(object->sha1);
+			shallow_nr++;
+		}
+		result = result->next;
+	}
+	free_commit_list(backup);
+	for (i = 0; i < shallows->nr; i++) {
+		struct object *object = shallows->objects[i].item;
+		if (object->flags & NOT_SHALLOW) {
+			struct commit_list *parents;
+			packet_write(1, "unshallow %s",
+				     sha1_to_hex(object->sha1));
+			object->flags &= ~CLIENT_SHALLOW;
+			/* make sure the real parents are parsed */
+			unregister_shallow(object->sha1);
+			object->parsed = 0;
+			parse_commit_or_die((struct commit *)object);
+			parents = ((struct commit *)object)->parents;
+			while (parents) {
+				add_object_array(&parents->item->object,
+						 NULL, &want_obj);
+				parents = parents->next;
+			}
+			add_object_array(object, NULL, &extra_edge_obj);
+		}
+		/* make sure commit traversal conforms to client */
+		register_shallow(object->sha1);
+	}
+	packet_flush(1);
+}
+
 static void receive_needs(void)
 {
 	struct object_array shallows = OBJECT_ARRAY_INIT;
@@ -623,53 +672,9 @@ static void receive_needs(void)
 
 	if (depth == 0 && shallows.nr == 0)
 		return;
-	if (depth > 0) {
-		struct commit_list *result = NULL, *backup = NULL;
-		int i;
-		if (depth == INFINITE_DEPTH && !is_repository_shallow())
-			for (i = 0; i < shallows.nr; i++) {
-				struct object *object = shallows.objects[i].item;
-				object->flags |= NOT_SHALLOW;
-			}
-		else
-			backup = result =
-				get_shallow_commits(&want_obj, depth,
-						    SHALLOW, NOT_SHALLOW);
-		while (result) {
-			struct object *object = &result->item->object;
-			if (!(object->flags & (CLIENT_SHALLOW|NOT_SHALLOW))) {
-				packet_write(1, "shallow %s",
-						sha1_to_hex(object->sha1));
-				register_shallow(object->sha1);
-				shallow_nr++;
-			}
-			result = result->next;
-		}
-		free_commit_list(backup);
-		for (i = 0; i < shallows.nr; i++) {
-			struct object *object = shallows.objects[i].item;
-			if (object->flags & NOT_SHALLOW) {
-				struct commit_list *parents;
-				packet_write(1, "unshallow %s",
-					sha1_to_hex(object->sha1));
-				object->flags &= ~CLIENT_SHALLOW;
-				/* make sure the real parents are parsed */
-				unregister_shallow(object->sha1);
-				object->parsed = 0;
-				parse_commit_or_die((struct commit *)object);
-				parents = ((struct commit *)object)->parents;
-				while (parents) {
-					add_object_array(&parents->item->object,
-							NULL, &want_obj);
-					parents = parents->next;
-				}
-				add_object_array(object, NULL, &extra_edge_obj);
-			}
-			/* make sure commit traversal conforms to client */
-			register_shallow(object->sha1);
-		}
-		packet_flush(1);
-	} else
+	if (depth > 0)
+		deepen(depth, &shallows);
+	else
 		if (shallows.nr > 0) {
 			int i;
 			for (i = 0; i < shallows.nr; i++)
-- 
2.3.0.rc1.137.g477eb31

[PATCH 2/6] upload-pack: move "shallow" sending code out of deepen()

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 upload-pack.c | 25 +++++++++++++++----------
 1 file changed, 15 insertions(+), 10 deletions(-)

diff --git a/upload-pack.c b/upload-pack.c
index 74f48f9..ea030f3 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -531,6 +531,20 @@ error:
 	}
 }
 
+static void send_shallow(struct commit_list *result)
+{
+	while (result) {
+		struct object *object = &result->item->object;
+		if (!(object->flags & (CLIENT_SHALLOW|NOT_SHALLOW))) {
+			packet_write(1, "shallow %s",
+				     sha1_to_hex(object->sha1));
+			register_shallow(object->sha1);
+			shallow_nr++;
+		}
+		result = result->next;
+	}
+}
+
 static void deepen(int depth, const struct object_array *shallows)
 {
 	struct commit_list *result = NULL, *backup = NULL;
@@ -544,16 +558,7 @@ static void deepen(int depth, const struct object_array *shallows)
 		backup = result =
 			get_shallow_commits(&want_obj, depth,
 					    SHALLOW, NOT_SHALLOW);
-	while (result) {
-		struct object *object = &result->item->object;
-		if (!(object->flags & (CLIENT_SHALLOW|NOT_SHALLOW))) {
-			packet_write(1, "shallow %s",
-				     sha1_to_hex(object->sha1));
-			register_shallow(object->sha1);
-			shallow_nr++;
-		}
-		result = result->next;
-	}
+	send_shallow(result);
 	free_commit_list(backup);
 	for (i = 0; i < shallows->nr; i++) {
 		struct object *object = shallows->objects[i].item;
-- 
2.3.0.rc1.137.g477eb31

[PATCH 3/6] upload-pack: remove unused variable "backup"

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 upload-pack.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/upload-pack.c b/upload-pack.c
index ea030f3..79f5525 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -547,7 +547,7 @@ static void send_shallow(struct commit_list *result)
 
 static void deepen(int depth, const struct object_array *shallows)
 {
-	struct commit_list *result = NULL, *backup = NULL;
+	struct commit_list *result = NULL;
 	int i;
 	if (depth == INFINITE_DEPTH && !is_repository_shallow())
 		for (i = 0; i < shallows->nr; i++) {
@@ -555,11 +555,11 @@ static void deepen(int depth, const struct object_array *shallows)
 			object->flags |= NOT_SHALLOW;
 		}
 	else
-		backup = result =
+		result =
 			get_shallow_commits(&want_obj, depth,
 					    SHALLOW, NOT_SHALLOW);
 	send_shallow(result);
-	free_commit_list(backup);
+	free_commit_list(result);
 	for (i = 0; i < shallows->nr; i++) {
 		struct object *object = shallows->objects[i].item;
 		if (object->flags & NOT_SHALLOW) {
-- 
2.3.0.rc1.137.g477eb31

[PATCH 4/6] upload-pack: move "unshallow" sending code out of deepen()

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 upload-pack.c | 33 ++++++++++++++++++++-------------
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/upload-pack.c b/upload-pack.c
index 79f5525..69a3828 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -545,21 +545,10 @@ static void send_shallow(struct commit_list *result)
 	}
 }
 
-static void deepen(int depth, const struct object_array *shallows)
+static void send_unshallow(const struct object_array *shallows)
 {
-	struct commit_list *result = NULL;
 	int i;
-	if (depth == INFINITE_DEPTH && !is_repository_shallow())
-		for (i = 0; i < shallows->nr; i++) {
-			struct object *object = shallows->objects[i].item;
-			object->flags |= NOT_SHALLOW;
-		}
-	else
-		result =
-			get_shallow_commits(&want_obj, depth,
-					    SHALLOW, NOT_SHALLOW);
-	send_shallow(result);
-	free_commit_list(result);
+
 	for (i = 0; i < shallows->nr; i++) {
 		struct object *object = shallows->objects[i].item;
 		if (object->flags & NOT_SHALLOW) {
@@ -582,6 +571,24 @@ static void deepen(int depth, const struct object_array *shallows)
 		/* make sure commit traversal conforms to client */
 		register_shallow(object->sha1);
 	}
+}
+
+static void deepen(int depth, const struct object_array *shallows)
+{
+	struct commit_list *result = NULL;
+	int i;
+	if (depth == INFINITE_DEPTH && !is_repository_shallow())
+		for (i = 0; i < shallows->nr; i++) {
+			struct object *object = shallows->objects[i].item;
+			object->flags |= NOT_SHALLOW;
+		}
+	else
+		result =
+			get_shallow_commits(&want_obj, depth,
+					    SHALLOW, NOT_SHALLOW);
+	send_shallow(result);
+	free_commit_list(result);
+	send_unshallow(shallows);
 	packet_flush(1);
 }
 
-- 
2.3.0.rc1.137.g477eb31

[PATCH 5/6] shallow.c: implement a generic shallow boundary finder based on rev-list

[Nguyễn Thái Ngọc Duy]

Instead of a custom commit walker like get_shallow_commits(), this new
function uses rev-list to mark SHALLOW to all reachable commits. The
definition of reachable is to be defined by the protocol later. This
makes it more flexible to define shallow boundary.

Note: if a commit has one not_shallow parent and one shallow parent,
then it's considered the boundary. Which means in the client side,
this commit has _no_ parents. This could lead to surprising cuts if
we're not careful.

Another option is to include more commits and only mark commits whose
all parents are not-shallow as boundary.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 commit.h  |  2 ++
 shallow.c | 65 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 2 files changed, 67 insertions(+)

diff --git a/commit.h b/commit.h
index 9f189cb..5c80eea 100644
--- a/commit.h
+++ b/commit.h
@@ -254,6 +254,8 @@ extern int for_each_commit_graft(each_commit_graft_fn, void *);
 extern int is_repository_shallow(void);
 extern struct commit_list *get_shallow_commits(struct object_array *heads,
 		int depth, int shallow_flag, int not_shallow_flag);
+extern struct commit_list *get_shallow_commits_by_rev_list(
+		int ac, const char **av, int shallow_flag, int not_shallow_flag);
 extern void set_alternate_shallow_file(const char *path, int override);
 extern int write_shallow_commits(struct strbuf *out, int use_pack_protocol,
 				 const struct sha1_array *extra);
diff --git a/shallow.c b/shallow.c
index d8bf40a..1db2768 100644
--- a/shallow.c
+++ b/shallow.c
@@ -10,6 +10,8 @@
 #include "revision.h"
 #include "commit-slab.h"
 #include "sigchain.h"
+#include "revision.h"
+#include "list-objects.h"
 
 static int is_shallow = -1;
 static struct stat_validity shallow_stat;
@@ -137,6 +139,69 @@ struct commit_list *get_shallow_commits(struct object_array *heads, int depth,
 	return result;
 }
 
+static void show_commit(struct commit *commit, void *data)
+{
+	commit->object.flags |= *(int *)data;
+}
+
+struct commit_list *get_shallow_commits_by_rev_list(int ac, const char **av,
+						    int shallow_flag, int not_shallow_flag)
+{
+	struct commit_list *result = NULL;
+	struct rev_info revs;
+	unsigned int i, nr;
+
+	/*
+	 * SHALLOW and NOT_SHALLOW should not be set at this
+	 * point. But better be safe than sorry.
+	 */
+	nr = get_max_object_index();
+	for (i = 0; i < nr; i++) {
+		struct object *o = get_indexed_object(i);
+		o->flags &= ~(shallow_flag | not_shallow_flag);
+	}
+
+	is_repository_shallow(); /* make sure shallows are read */
+
+	init_revisions(&revs, NULL);
+	save_commit_buffer = 0;
+	setup_revisions(ac, av, &revs, NULL);
+
+	/* mark all reachable commits as SHALLOW */
+	if (prepare_revision_walk(&revs))
+		die("revision walk setup failed");
+	traverse_commit_list(&revs, show_commit, NULL, &shallow_flag);
+
+	nr = get_max_object_index();
+	for (i = 0; i < nr; i++) {
+		struct object *o = get_indexed_object(i);
+		struct commit *c = (struct commit *)o;
+		struct commit_list *p;
+		int parent_is_not_shallow = 0;
+
+		if (o->type != OBJ_COMMIT || !(o->flags & shallow_flag))
+			continue;
+
+		if (parse_commit(c))
+			die("unable to parse commit %s",
+			    sha1_to_hex(c->object.sha1));
+
+		for (p = c->parents; p; p = p->next) {
+			if (p->item->object.flags & shallow_flag)
+				continue;
+			parent_is_not_shallow = 1;
+			if (p->item->object.flags & not_shallow_flag)
+				continue;
+			p->item->object.flags |= not_shallow_flag;
+			commit_list_insert(p->item, &result);
+		}
+
+		if (parent_is_not_shallow)
+			commit_list_insert(c, &result);
+	}
+	return result;
+}
+
 static void check_shallow_file_for_update(void)
 {
 	if (is_shallow == -1)
-- 
2.3.0.rc1.137.g477eb31

[PATCH 6/6] upload-pack: example code to use get_shallow_commits_by_rev_list

[Nguyễn Thái Ngọc Duy]

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
 upload-pack.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/upload-pack.c b/upload-pack.c
index 69a3828..e616e19 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -592,6 +592,18 @@ static void deepen(int depth, const struct object_array *shallows)
 	packet_flush(1);
 }
 
+static void deepen_by_rev_list(int ac, const char **av,
+			       struct object_array *shallows)
+{
+	struct commit_list *result;
+
+	result = get_shallow_commits_by_rev_list(ac, av, SHALLOW, NOT_SHALLOW);
+	send_shallow(result);
+	free_commit_list(result);
+	send_unshallow(shallows);
+	packet_flush(1);
+}
+
 static void receive_needs(void)
 {
 	struct object_array shallows = OBJECT_ARRAY_INIT;
@@ -686,6 +698,12 @@ static void receive_needs(void)
 		return;
 	if (depth > 0)
 		deepen(depth, &shallows);
+#if 0
+	else if (since_is_specified) {
+		/* prepare ac, av */
+		deepen_by_rev_list(ac, av, &shallows);
+	}
+#endif
 	else
 		if (shallows.nr > 0) {
 			int i;
-- 
2.3.0.rc1.137.g477eb31

Re: [RFH] GSoC 2015 application

[Duy Nguyen]

On Thu, Feb 19, 2015 at 2:14 AM, Jeff King <peff@peff.net> wrote:
> Where I really need help now is in the "ideas" page:
>
>   http://git.github.io/SoC-2015-Ideas.html

Is this too ambitious for a summer? I suspect the answer is yes, but anyway..

Due to http limitations and stateless decision, a lot of data is sent
back and forth during have/want negotiation for smart-http. I wonder
if we could implement the "long polling" scheme in a CGI program. The
program terminates HTTP requests and recreates a full duplex
connection for upload-pack to talk to the client. upload-pack falls
back to the normal mode, used by git:// and ssh://.

An example of this is BOSH [1]. From a quick glance it does not seem
to require any special thing, so it's unlikely to cause problems with
firewalls, proxies.. If this is implemented as cgi (instead of http
server), we'll need to save session infos somewhere. I suppose shm
with proper locking is enough.

[1] http://xmpp.org/extensions/xep-0124.html
-- 
Duy

Re: [RFH] GSoC 2015 application

[Jeff King]

On Thu, Feb 26, 2015 at 08:10:38PM +0700, Duy Nguyen wrote:

> On Thu, Feb 19, 2015 at 2:14 AM, Jeff King <peff@peff.net> wrote:
> > Where I really need help now is in the "ideas" page:
> >
> >   http://git.github.io/SoC-2015-Ideas.html
> 
> Is this too ambitious for a summer? I suspect the answer is yes, but anyway..
> 
> Due to http limitations and stateless decision, a lot of data is sent
> back and forth during have/want negotiation for smart-http. I wonder
> if we could implement the "long polling" scheme in a CGI program. The
> program terminates HTTP requests and recreates a full duplex
> connection for upload-pack to talk to the client. upload-pack falls
> back to the normal mode, used by git:// and ssh://.

So basically Git-over-TCP-over-HTTP? :)

That would be a nice thing to have, though looking over the BOSH link
(which this is my first exposure to), it does look rather complicated.
It's not clear to me how easily one could plug in an existing tunneling
solution, and just stick git programs at the endpoints (in other words,
let that solution manage all of the connection state and just present a
socketpair() to git).

I'm not sure it is too ambitious in terms of actual implementation time,
but I think the design work may exceed what most students are capable
of.

-Peff

Re: [RFH] GSoC 2015 application

[Duy Nguyen]

On Wed, Mar 4, 2015 at 5:31 PM, Jeff King <peff@peff.net> wrote:
> On Thu, Feb 26, 2015 at 08:10:38PM +0700, Duy Nguyen wrote:
>
>> On Thu, Feb 19, 2015 at 2:14 AM, Jeff King <peff@peff.net> wrote:
>> > Where I really need help now is in the "ideas" page:
>> >
>> >   http://git.github.io/SoC-2015-Ideas.html
>>
>> Is this too ambitious for a summer? I suspect the answer is yes, but anyway..
>>
>> Due to http limitations and stateless decision, a lot of data is sent
>> back and forth during have/want negotiation for smart-http. I wonder
>> if we could implement the "long polling" scheme in a CGI program. The
>> program terminates HTTP requests and recreates a full duplex
>> connection for upload-pack to talk to the client. upload-pack falls
>> back to the normal mode, used by git:// and ssh://.
>
> So basically Git-over-TCP-over-HTTP? :)

Yes. The hidden agenda was, if it works well, we might be able to
deprecate smart-http one day. That day, if happens, would be in far
future though. By that time hopefully we could just use http2
insteadof tcp-over-http1.

> I'm not sure it is too ambitious in terms of actual implementation time,
> but I think the design work may exceed what most students are capable
> of.

Not to mention that I think it can be man-in-the-middle attacked if
we're not careful (e.g. send to session token in unencrypted). Which
makes it less appealing to me.
-- 
Duy