On Mon, Mar 27, 2017 at 4:58 AM, Jeff King wrote:
> On Sun, Mar 26, 2017 at 05:36:21PM -0700, Junio C Hamano wrote:
>
>> It's not "potential confusion". This closes the door for us to
>> introduce "TREE" as a separate object type in the future.
>>
>> If we agree to make a
On Sun, Mar 26, 2017 at 10:39:18PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > FWIW, I cannot see us ever adding TREE (or Tree) as a separate type.
> > It's too confusing for no gain. We'd call it "tree2" or something more
> > obvious.
>
> In case it was not clear, I
Jeff King writes:
> FWIW, I cannot see us ever adding TREE (or Tree) as a separate type.
> It's too confusing for no gain. We'd call it "tree2" or something more
> obvious.
In case it was not clear, I didn't mean to say I _want_ to leave
that door open. Well, I cannot imagine it
On Sun, Mar 26, 2017 at 05:36:21PM -0700, Junio C Hamano wrote:
> It's not "potential confusion". This closes the door for us to
> introduce "TREE" as a separate object type in the future.
>
> If we agree to make a declaration that all typenames are officially
> spelled in lowercase [*1*] and
Ævar Arnfjörð Bjarmason writes:
> Change the revision parsing logic to match ^{commit}, ^{tree}, ^{blob}
> etc. case-insensitively.
>
> Before this change supplying anything except the lower-case forms
> emits an "unknown revision or path not in the working tree"
> error. This
Change the revision parsing logic to match ^{commit}, ^{tree}, ^{blob}
etc. case-insensitively.
Before this change supplying anything except the lower-case forms
emits an "unknown revision or path not in the working tree"
error. This change makes upper-case & mixed-case versions equivalent
to the
6 matches
Mail list logo