From: Philip Oakley <philipoakley@iee.org>
Date: Wed, 04 Mar 2015 23:59:48 GMT
Subject: Re: [RFH] GSoC 2015 application
Message-ID: <75FBE31490904D8EA82F5C445F1F33E1@PhilipOakley>
In-Reply-To: <CAGZ79kaNZsBP19gLvsrDx6RLyQ7QhmbKAgSDcXg71Uwcvf9tNQ@mail.gmail.com>

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