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

[Michael Haggerty <mhagger@alum.mit.edu>]

On 11/07/2015 12:24 AM, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
>> Michael Haggerty <mhagger@alum.mit.edu> writes:
>>
>>> [...] And then, if you are also OK with the
>>> new subdirectory introduced in this patch series, David and I seem to be
>>> in agreement that it is ready to go. It would be great if this patch
>>> series could be merged in a timely manner, as it will conflict with
>>> nearly any other changes that people might want to undertake in the refs
>>> code.
>>
>> Thanks for working well together.  Let me see what I can do today...
> 
> What I'll push out later today merges this to the tip of 'pu'.
> The resolution is the same for 'jch' or 'next' (I checked).
> 
> I have to say that the merge of this topioc is not pretty.  [...]

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. And maybe the correctness
of our series in its current form isn't quite obvious enough.

David and I will be the ones who benefit most from having this resolved
quickly, because there is lots more work that has to be done after the
code movement and it is kindof hard to continue that work while this
topic is up in the air.

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.

The first idea would be a couple of hours of work (including adjusting
comments and commit messages). The second and third ideas would probably
best be done in combination, and might take a day or two of work because
they involve reordering patches.

Let us know what you think.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu