Re: [PATCH v6 25/25] refs: break out ref conflict checks

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

 



Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:

> I hate to cause the maintainer extra work. I guess I was making two
> naive assumptions:
>
> * If we make the code-movement series simple and "obviously correct"
>   enough, then it could be merged pretty much straight through to
>   master.
>
> * If one or two topics conflict with the code movement, they could
>   be one-time rebased on top of the new master (I would be willing
>   to do this work).
>
> Maybe neither of these assumptions is valid.

It is sometimes necessary to declare "This is important, and it is
solid enough. Let's fast-track it.  Other people must work on top of
this." and make a project-wide decision to do so.  It was just that
was not doable within the time I had before I had to hand the tree
off.

You can still work with the other people involved (Lukas as the
ref-is-hidden topic contributor and Peff as the interim maintainer)
to make it happen, and I wouldn't be upset.

> I can see a few ways that we could make our series even more
> straightforward:
>
> 1. Leave refs.c in its original location (as suggested by Junio).
>    Optionally, it could be moved at a later date when this area is
>    quiescent.
>
> 2. Move content selectively from refs.c to refs/files-backend.c rather
>    than moving the whole file there and then moving content selectively
>    back to refs/refs.c.
>
> 3. Separate *all* of the non-obvious changes into a preparatory
>    patch series, to be followed by a separate patch series that *only*
>    moves code.

4. Move everything in the series as-is, *BUT* in each patch where
the series moved things to refs/refs.c from refs/files-backend.c,
move that back to refs.c instead.  No refs/refs.c anywhere in the
history or in the endgame.

I think having refs.h and refs.c at the toplevel for the public
interface, with refs/ hierarchy holding backend specifics, would be
a good organization for the endgame regardless of the conflicts with
in-flight topics, and 4. achieves that.  Perhaps you meant the same
thing as your 1.

As to the reordering of functions and structure defs, I am
reasonably sure that the order in the final refs/refs.c in your
series would be better thought-out than in the original refs.c, so
the "reorder stuff in refs.c" can be the first step before
everything is moved to refs/files-backend.c, perhaps?

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[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]