On Fri, Sep 07, 2018 at 12:23:53AM -0700, Jonathan Nieder wrote:
> Ævar Arnfjörð Bjarmason wrote:
> > If this turns out to be a common use-case perhaps the easiest way to
> > support that would be to make the hashmap (optionally?) ordered, as Ruby
> > 1.9 did with their hash implementation:
> >
On Thu, Sep 06, 2018 at 11:32:41PM -0700, Jonathan Nieder wrote:
> > I think Stefan pointed out a "case 4" in the other part of the thread:
> > ones where we really care not just about fast lookup, but actual
> > iteration order.
>
> I had assumed that that was the whole point of this data
Ævar Arnfjörð Bjarmason wrote:
> On Fri, Sep 07 2018, Jonathan Nieder wrote:
>> Jeff King wrote:
>>> I don't see any point in generating a sorted list and _then_ making an
>>> auxiliary hashmap. My idea was that if you're using a sorted string-list
>>> for lookup, then you can replace the whole
On Fri, Sep 07 2018, Jonathan Nieder wrote:
> Jeff King wrote:
>
>> I don't see any point in generating a sorted list and _then_ making an
>> auxiliary hashmap. My idea was that if you're using a sorted string-list
>> for lookup, then you can replace the whole thing with a hash (inserting
>> as
Jeff King wrote:
> I don't see any point in generating a sorted list and _then_ making an
> auxiliary hashmap. My idea was that if you're using a sorted string-list
> for lookup, then you can replace the whole thing with a hash (inserting
> as you go, rather than sorting at the end).
What if I'm
On Thu, Sep 06, 2018 at 04:50:33PM -0700, Jonathan Nieder wrote:
> Hi,
>
> Jeff King wrote:
>
> > But what I think is harmful is a _sorted_ list, because of the
> > "accidentally quadratic" nature, and because it's easy to call its
> > functions on an unsorted list.
>
> I agree --- in general,
On Thu, Sep 06, 2018 at 01:54:15PM -0700, Stefan Beller wrote:
> > > It turns out we make never use of a custom compare function in
> > > the stringlist, which helps gaining confidence this use case is nowhere
> > > to be found in the code.
> >
> > Plenty of code uses the default strcmp. You can
Hi,
Jeff King wrote:
> But what I think is harmful is a _sorted_ list, because of the
> "accidentally quadratic" nature, and because it's easy to call its
> functions on an unsorted list.
I agree --- in general, it tends to be better to build an unsorted
string list and then sort it.
Once I've
> > Does a hashmap guarantee an order?
>
> No, it definitely doesn't.
>
> I guess the reading-between-the-lines assumption that I didn't quite say
> is: I think most (if not all) of the users of sorted string lists don't
> actually care about a particular order. They just want efficient lookup.
>
On Thu, Sep 06, 2018 at 01:04:18PM -0700, Stefan Beller wrote:
> On Thu, Sep 6, 2018 at 12:12 PM Jeff King wrote:
> >
> > On Thu, Sep 06, 2018 at 10:59:42AM -0400, Jeff King wrote:
> >
> > > > + string_list_append(_list, *argv[0]);
> > >
> > > This will create an unsorted list. You'd
On Thu, Sep 6, 2018 at 12:12 PM Jeff King wrote:
>
> On Thu, Sep 06, 2018 at 10:59:42AM -0400, Jeff King wrote:
>
> > > + string_list_append(_list, *argv[0]);
> >
> > This will create an unsorted list. You'd have to use
> > string_list_insert() here for a sorted list, or
> >
On 06.09.18 20:40, Junio C Hamano wrote:
Jeff King writes:
On Thu, Sep 06, 2018 at 12:16:58PM +0200, Tim Schumacher wrote:
@@ -691,17 +692,23 @@ static int run_argv(int *argcp, const char ***argv)
/* .. then try the external ones */
On Thu, Sep 06, 2018 at 03:12:03PM -0400, Jeff King wrote:
> On Thu, Sep 06, 2018 at 10:59:42AM -0400, Jeff King wrote:
>
> > > + string_list_append(_list, *argv[0]);
> >
> > This will create an unsorted list. You'd have to use
> > string_list_insert() here for a sorted list, or
> >
On Thu, Sep 06, 2018 at 09:05:50PM +0200, Tim Schumacher wrote:
> On 06.09.18 16:57, Jeff King wrote:
> > On Thu, Sep 06, 2018 at 04:01:39PM +0200, Ævar Arnfjörð Bjarmason wrote:
> >
> > > If we don't have some test for these sort of aliasing loops that fails
> > > now, we really should add that
On Thu, Sep 06, 2018 at 10:59:42AM -0400, Jeff King wrote:
> > + string_list_append(_list, *argv[0]);
>
> This will create an unsorted list. You'd have to use
> string_list_insert() here for a sorted list, or
> unsorted_string_list_has_string() in the earlier call.
>
> It's
On 06.09.18 16:57, Jeff King wrote:
On Thu, Sep 06, 2018 at 04:01:39PM +0200, Ævar Arnfjörð Bjarmason wrote:
If we don't have some test for these sort of aliasing loops that fails
now, we really should add that in a 1/2 and fix it in this patch in 2/2.
Yes, I'd agree that this is worth
On Thu, Sep 06, 2018 at 11:40:14AM -0700, Junio C Hamano wrote:
> Also, normal users who have never seen this loop that implements
> alias expansion would not have a clue when they see "called twice".
>
> I actually think the caller should also pass cmd to run_argv() and
> then we should use it
Jeff King writes:
> On Thu, Sep 06, 2018 at 12:16:58PM +0200, Tim Schumacher wrote:
>
>> @@ -691,17 +692,23 @@ static int run_argv(int *argcp, const char ***argv)
>> /* .. then try the external ones */
>> execv_dashed_external(*argv);
>>
>> -/* It could be
On Thu, Sep 06, 2018 at 05:10:04PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > seen = unsorted_string_list_lookup(_list, *argv[0]);
> > if (seen) {
> > for (i = 0; i < cmd_list.nr; i++) {
> > struct string_list *item = cmd_list.items[i];
> >
> > strbuf_addf(, "
On Thu, Sep 06 2018, Jeff King wrote:
> On Thu, Sep 06, 2018 at 04:01:39PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> If we don't have some test for these sort of aliasing loops that fails
>> now, we really should add that in a 1/2 and fix it in this patch in 2/2.
>
> Yes, I'd agree that this
On Thu, Sep 06, 2018 at 12:16:58PM +0200, Tim Schumacher wrote:
> @@ -691,17 +692,23 @@ static int run_argv(int *argcp, const char ***argv)
> /* .. then try the external ones */
> execv_dashed_external(*argv);
>
> - /* It could be an alias -- this works
On Thu, Sep 06, 2018 at 04:01:39PM +0200, Ævar Arnfjörð Bjarmason wrote:
> If we don't have some test for these sort of aliasing loops that fails
> now, we really should add that in a 1/2 and fix it in this patch in 2/2.
Yes, I'd agree that this is worth adding a test (especially if the
output
On Thu, Sep 06 2018, Tim Schumacher wrote:
> Aliases can only contain non-alias git commands and their
> arguments, not other user-defined aliases. Resolving further
> (nested) aliases is prevented by breaking the loop after the
> first alias was processed. Git then fails with a
Aliases can only contain non-alias git commands and their
arguments, not other user-defined aliases. Resolving further
(nested) aliases is prevented by breaking the loop after the
first alias was processed. Git then fails with a command-not-found
error.
Allow resolving nested aliases by not
24 matches
Mail list logo
