Re: [PATCH 2/6] commit-graph.h: store object directory in 'struct commit_graph'

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

 



On Fri, Jan 31, 2020 at 05:20:49AM -0500, Jeff King wrote:
> On Fri, Jan 31, 2020 at 07:52:02AM +0100, Martin Ågren wrote:
>
> > > --- a/commit-graph.c
> > > +++ b/commit-graph.c
> >
> > > +struct object_directory *find_odb(struct repository *r, const char *obj_dir)
> >
> > This doesn't look commit-graph related -- could/should it go somewhere
> > else?
>
> I think the right place is actually as a static inside
> builtin/commit-graph.c, as this is really about handling its weird
> --object-dir options.
>
> But it can't go there in this patch, because there's a caller in
> commit-graph.c. In patch 4, we convert write_commit_graph() to take an
> odb, too, and that call goes away. At that point, we could move it into
> the builtin as a static.
>
> Ideally we could flip the order of this patch and patch 4, but that
> doesn't work either: by switching to an odb we lose our path
> normalization, but if the other side hasn't switched either, then we
> can't just compare odb pointers. It would be a temporary regression.
>
> So there's a circular dependency between the two patches. I think we
> ought to do done of:
>
>   - move find_odb() to a static as a cleanup on top
>
>   - squash those two patches together into a single
>
>   - swap the patch order, but have write_commit_graph_ctx store both the
>     "odb" _and_ the normalized copy of the path we do now. That leaves
>     it correct, and then it can be cleaned up in favor of an odb pointer
>     comparison in patch 5, along with the rest of the normalized bits.

Thanks for describing the problem, and for laying out a few options!

I went with this option, which was to swap patches 2/6 and 4/6, and then
squashing 3/6 into what _was_ 4/6 (but is now 2/5).

That all said, I am not sure that I follow the explanation that we need
to have 'write_commit_graph_ctx' store the normalized object_dir, since
we can use 'odb->path' for this instead. I double checked, and we
already do the same loose normalization in
'sha1-file.c:link_alt_odb_entry()', where we remove trailing slashes.

This isn't the exact same normalization strictly speaking. It differs
only in that we remove more than one trailing slash if it exists, but
this seems acceptable for the 2 patches that this behavior changes lives
on for.

I double checked that the 'odb->path' is normalized relative to the $PWD,
in which case I think that we can rely on it as a stand-in for
'object_dir', and don't have to store both.

> I'm OK with any of those. The second two have the added bonus that we
> could introduce the die() behavior into find_odb() immediately, and
> explain it (there's another temporary weirdness in this patch where
> specifying an --object-dir outside of the repository becomes a silent
> noop, and then the next patch turns it into an error, but that could all
> be done in a single step when we introduce find_odb()).
>
> > I think you could drop `cmp` and that final check, and write the loop
> > body as "if (!strcmp(...)) break". You could also have an empty loop
> > body, but I wouldn't go there -- I'd find that less readable. (Maybe
> > that's just me.)
>
> Yeah, I believe you are correct (and this is a nice simplification worth
> doing).
>
> -Peff

Thanks,
Taylor



[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