From: "Philip Oakley"
s/with/without/ ...
From: "Junio C Hamano"
: Friday, November 10, 2017 1:24 AM
[catch up]
"Philip Oakley" writes:
From: "Stefan Beller"
Rereading this discussion, there is
From: "Junio C Hamano"
: Friday, November 10, 2017 1:24 AM
[catch up]
"Philip Oakley" writes:
From: "Stefan Beller"
Rereading this discussion, there is currently no urgent thing to
address?
True.
Then the state as announced
"Philip Oakley" writes:
> From: "Stefan Beller"
>> Rereading this discussion, there is currently no urgent thing to address?
>
> True.
>
>> Then the state as announced by the last cooking email, to just cook
>> it, seems
>> about right and we'll wait
From: "Stefan Beller"
Rereading this discussion, there is currently no urgent thing to address?
True.
Then the state as announced by the last cooking email, to just cook it,
seems
about right and we'll wait for further feedback.
Possibly only checking the documenation
Rereading this discussion, there is currently no urgent thing to address?
Then the state as announced by the last cooking email, to just cook it, seems
about right and we'll wait for further feedback.
Thanks,
Stefan
From: "Junio C Hamano"
Sent: Sunday, November 05, 2017 6:28 AM
"Philip Oakley" writes:
Is this not also an alternative case, relative to the user, for the
scenario where the user has an oid/sha1 value but does not know what
it is, and would like to
"Philip Oakley" writes:
> Is this not also an alternative case, relative to the user, for the
> scenario where the user has an oid/sha1 value but does not know what
> it is, and would like to find its source and type relative to the
> `describe` command.
I am not sure what
From: "Junio C Hamano"
Sent: Thursday, November 02, 2017 4:23 AM
Junio C Hamano writes:
The reason why we say "-ish" is "Yes we know v2.15.0 is *NOT* a
commit object, we very well know it is a tag object, but because we
allow it to be used in a context
Junio C Hamano writes:
> The reason why we say "-ish" is "Yes we know v2.15.0 is *NOT* a
> commit object, we very well know it is a tag object, but because we
> allow it to be used in a context that calls for a commit object, we
> mark that use context as 'this accepts
Stefan Beller writes:
> But now we have a path as well, the notation of
> COLON
> is not a unique description of the blob, because
> * there can be multiple s depending on the tags and walking
> * in boilerplate code cases, we might even have the blob at different
>
On Tue, Oct 31, 2017 at 8:34 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>>> Given the difficulty in
>>> coming up with the single-liner description of what it does we saw
>>> above, I suspect that splitting SYNOPSIS out into two very distinct
>>>
Stefan Beller writes:
> Maybe
>
> "git-describe - Describe a blob or commit using graph relations"
>
> though that sounds too generic, but it is accurate as all we do is
> a heuristic for graph walk ways.
We used to describe commit using commit ancestry (i.e. finding the
Stefan Beller writes:
>> Given the difficulty in
>> coming up with the single-liner description of what it does we saw
>> above, I suspect that splitting SYNOPSIS out into two very distinct
>> operating mode might make it easier to read.
>>
>> SYNOPSIS
>>
>>
On Mon, Oct 30, 2017 at 11:25 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
>> index c924c945ba..3d618b2445 100644
>> --- a/Documentation/git-describe.txt
>> +++
Stefan Beller writes:
> diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
> index c924c945ba..3d618b2445 100644
> --- a/Documentation/git-describe.txt
> +++ b/Documentation/git-describe.txt
> @@ -3,7 +3,7 @@ git-describe(1)
>
> NAME
>
>
Sometimes users are given a hash of an object and they want to
identify it further (ex.: Use verify-pack to find the largest blobs,
but what are these? or [1])
"This is an interesting endeavor, because describing things is hard."
-- me, upon writing this patch.
When describing commits, we try
16 matches
Mail list logo