From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 05 Mar 2015 01:17:52 GMT
Subject: Re: [RFH] GSoC 2015 application
Message-ID: <xmqqr3t45jjz.fsf@gitster.dls.corp.google.com>
In-Reply-To: <CAGZ79kZzB8-r2a4VGG23GL1ZqxY7c34391vMwVr09MnCV6Hqcg@mail.gmail.com>

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.