Junio C Hamano wrote:
> I think it is too premature to discuss _your_ code.  The patches do
> not even tell us anything about how much more work is needed to
> merely make Git with your patches work properly again.  For one
> thing, I suspect that you won't even be able to repack a repository
> that has OBJ_LINK only with the patches you posted.

Let me try to rephrase my original request: I'm an inexperienced
contributor trying to do something very ambitious.  Having authored a
huge part of it, Linus and you understand git-core much better than I
can ever hope to understand.  These are things that you need to tell
me after reading the patches.  I only have a rough idea to make Git
work properly with my patches again: I can't know for sure until I
write all the code.  What's more?  Your guess will probably be better
than mine after you read the code.

You're asking me to submit a perfect 40 or 50 part series that's a
potential candidate for merging.  I'm sorry to say this, but I'm
incapable of doing that without posting intermediate work and getting
help.  Frankly, it's a very unreasonable expectation; I don't think
anyone except you or Linus can even get close after making such a
fundamental change.

I might end up writing all the code (which I'm perfectly okay with),
and all I'm asking from you is to constantly keep picking my brain (by
reviewing my code and posting good critiques).  Am I being

> At this point the only thing that we can gain from reading your
> patch is that you can write C to do _something_, but that something
> is so fuzzily explained that we do not know what to make of that
> knowledge that you write good (or bad, we don't know) C.

C is irrelevant here: I'm not asking you for style/ structuring tips;
I'm asking you for a critique on the implementation of this idea.
Linus raised some good points after reading [0/7] that I countered,
and there isn't anything else either anyone can raise without reading
more.  Code speaks more clearly than the English in [0/7]: you should
be able to deduce a lot more intent and direction.

> It would be much more productive to learn what these specific issues
> X, Y and Z are, and if the problems you are having with existing
> solutions are really fundamental that need changes to object layer
> to solve.

To reiterate: link does not make possible something that is not
fundamentally _possible_ with a .githack and a 100k-line Perl script.
At its core, every variant of submodules does this.  What I'm
essentially proposing: break up the information in .githack into
smaller bits and create a new object type so it can be parsed by
git-core easily.  If you agree that my proposal doesn't make
impossible what was possible earlier, and that it makes life easier
for everyone, we should be good to go.

When the series matures, we can investigate the other implementations
in greater detail so we can pick out more optional fields to add to
the link object before getting it merged.  This is not the right time
to do that: we're currently trying to get git-core working with the
mandatory fields.

> I do not think we have heard anything concrete and usable about what
> you are trying to achieve yet.

I'll try to rephrase your concerns here:

0. We don't know if this approach will yield a mergeable series at
all, because it breaks so many things and is so difficult to complete.

1. We don't know how much work is needed to bring the series to a
point where it is in a mergeable state.  There is no timeline

2. We can't build an exhaustive list of the problems that this new
approach will solve (ie. we haven't finalized the optional fields).

3. We don't have anything useable yet.

And your non-concerns should be:

1. We know that this approach won't fundamentally limit us in not
being able to solve some specific problems that the .githack approach

2. We know that this approach makes life easier for everyone, and
there are significant concrete benefits to teaching git-core about

I agree with all this fully.  I don't have a concrete roadmap; we'll
just have to dive in based on what we've seen so far, and hope that
we're able to finish what we started.  So, my final question is: are
you still not convinced that this approach shows a lot of potential,
and is worth exploring now?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to