Re: [PATCH 00/21] Kill the_index part 4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Aug 27, 2018 at 7:32 PM Stefan Beller <sbeller@xxxxxxxxxx> wrote:
> > Besides some small conflicts on 'pu', like the previous part, it also
> > breaks 'pu' because of API changes. The fix is trivial though, just
> > prepend the_repository as the first argument for the broken function
> > calls.
>
> This sounds like a problem. I said the same when sending the
> object store lookup series, which ended via
> 3a2a1dc1707 (Merge branch 'sb/object-store-lookup', 2018-08-02)
> in master, but I do recall Junio being somewhat unhappy about it[1].
>
> By just adding the argument to the function, it might merge easily
> but not compile, which would have to be fixed up; and that object store
> series seemed to touch a lot of functions that were also used in series
> in-flight.

Which is why I state it clearly here so Junio could choose not to pick
this series up (I'm totally ok with that, I could wait until the dust
settles and send again).

Another option is me adding a patch that renames diff_setup() to
diff_setup2() or something that takes 'struct repository *', leaving
diff_setup() as a light wrapper around diff_setup2(). I would need to
wait until in-flight series are merged, then rename diff_setup2() back
to diff_setup(). Not sure if it's worth doing.

> >  diff.c                 | 259 +++++++++++++++++++++++------------------
>
> Ugh? That sounds like there is an interesting change coming.

Yeah. sequencer.c also needs struct repository in lots of places
(sha1-name.c comes second). But at least builtin/ code looks a lot
like it's supposed to be when 'struct repository *' is introduced, we
now have lots of function calls there that pass the_repository...
-- 
Duy



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux