Re: [RFH] GSoC 2015 application

["Philip Oakley" <philipoakley@iee.org>]

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