Ramkumar Ramachandra <artag...@gmail.com> writes:

> So we've thought about it for some time, and I really need you to
> start reviewing the code now.
>
> I'll just summarize what we've discussed so far:
> ...

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

You may be proposing to discard baby with bathwater.  We haven't
seen an evidence that the change is really worth having.  We do not
even know what you are trying to change, other than "I want to add a
new object type to largely replicate what is recorded in .gitmodules
file".  What are you trying to solve?

        I want to have a project for an appliance, that binds two
        projects, the kernel and the appliance's userspace.  The
        usual suspects to use to implement such a project would be
        Git submodule, repo, or Gitslave.

        I want to be able to do X and Y and Z in managing such a
        project.

        If I try to use submodule, I cannot see how I could make it
        do X for _this thing_, and it is not a bug in the
        implementation but is fundamental because of _this and
        that_.  If I try to use repo, ...... the same, and the same
        for Gitslave. ......

        I propose to add a new "gitlink" object recorded in the tree
        and in the index, and the said cases X, Y and Z can be
        solved in _such and such way_.  We cannot solve it without
        having a new "gitlink" object recorded in the tree object
        because of _this and that reason_.

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.

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.

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