Stefan Beller <[email protected]> writes:
> On Wed, Mar 4, 2015 at 4:22 PM, Junio C Hamano <[email protected]> wrote:
>> On Wed, Mar 4, 2015 at 4:17 PM, Philip Oakley <[email protected]> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
