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

From: Junio C Hamano <gitster@pobox.com>
To: Michael Haggerty <mhagger@alum.mit.edu>
Cc: David Turner <dturner@twopensource.com>,
	git@vger.kernel.org, Jeff King <peff@peff.net>
Subject: Re: [PATCH v6 25/25] refs: break out ref conflict checks
Date: Sun, 08 Nov 2015 10:23:23 -0800	[thread overview]
Message-ID: <xmqqziyo1hb8.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <563ED7A0.7040007@alum.mit.edu> (Michael Haggerty's message of "Sun, 08 Nov 2015 06:03:28 +0100")

Michael Haggerty <mhagger@alum.mit.edu> 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.