Re: [RFH] GSoC 2015 application

Stefan Beller [off-list ref] writes:

On Wed, Mar 4, 2015 at 4:22 PM, Junio C Hamano [off-list ref] wrote:

quoted

On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley [off-list ref] wrote:

quoted

quoted

   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.