On Mon, Jun 15, 2015 at 11:39:07AM -0700, Junio C Hamano wrote:
> Michael Haggerty <mhagger@xxxxxxxxxxxx> writes:
>
> > It would seem to make sense to add a test here that there are no
> > existing references, because that is how the function *should* be
> > used. But in fact, the "testgit" remote helper appears to call it
> > *after* having set up refs/remotes/<name>/HEAD and
> > refs/remotes/<name>/master, so we can't be so strict.
>
> Is "testgit" so hard to fix (or so sacred to break) that we want to
> sacrifice the quality of this part that is nearer to the core?
I do not think "testgit" is sacred; it is there to serve the needs of
git and not the other way around. But we do have to stop and think
whether what "testgit" is doing is representative of what a real
remote-helper might do.
It has been a while since I touched the remote-helper code (and it has
always been under-documented and confusing, from my recollection), but I
think it is not "testgit" that is making the refs, but rather that
"import"-style helpers will feed a data stream to git-fast-import
(actually the transport code does it on behalf of the remote).
So "fast-import" creates the refs, and then "clone" later wants to
recreate them. IMHO this is not ideal[1]; we should have fast-import create
the objects and report the ref tips, which can then be relayed to clone.
But with the way the code works now, this is not about fixing "testgit",
but rather would break any "import"-style helper.
Take all of that with a grain of salt, though. I might be totally wrong
about how this part of the code works.
-Peff
[1] This may also be buggy for regular fetches. E.g., do we correctly
respect "--force" (or lack thereof) and "+"-refspecs when importing?
I am not sure, as I think we may pass enough information to the
helper to handle this itself. But certainly if the responsibility
for updating refs was always in the caller (clone or fetch), then it
would follow the regular code path and Just Work.
--
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