Re: ctrl-z ignored by git; creates blobs from non-existent repos

From: Jeff King <peff@peff.net>
Date: Jan 15, 2023, 23:33 UTC
Message-ID: <Y8SNNeQ3fQdrf5Fi@coredump.intra.peff.net>
In-Reply-To: <Y8SCZvMu7DZZH1Pl@localhost.my.domain>

On Sun, Jan 15, 2023 at 05:47:02PM -0500, Crls wrote:

Show 12 quoted lines

> > Now, when you type ^Z, the git processes are stopped --- but the
> > objects are created already.
> 
> The directories exist not because ^Z is used, but because by the time
> git-clone prompts for a username, git is already set on what to do
> next. Correct? in other words, the process is shoved down my throat.
> Or the user's throat in this case. Or going by another analogy, it
> certainly sounds as if I meant: «Git, please git-clone such and such
> repo, but let me fix just a typo on the repo name before submitting
> it, pretty please» and then Git replies: «too late for that
> chick-a-doodle» and there it goes. It injects blobs all over (well,
> not all over but on the dir specified).

I don't know what you mean by "blobs" here, since we fail to download any Git objects at all, let alone blobs. But yes, Git creates the local repository, and then tries to fetch into it. So the directory is created before it even contacts the remote server at all, and you will see the same behavior whether the repository exists or not. And then if an error occurs, it will rolls back by deleting the newly-created repository.

It _could_ be possible to contact the server first, and only when things looked successful-ish, to create the local repository. But:

  1. The clone command is simply not written that way, and converting it
     now would be tricky. The clone command's view of the world is that
     it makes a new repository, sets up config, etc, then fetches into
     it.

  2. It would not fix all cases anyway. At some point we have to say
     "this looks close enough to success to create the directory", but
     things can still go wrong after that.

Now if you have a problem with the rollback, there might be a bug there. But it sounds like you are simply stopping the process and not letting it finish. It should roll back even if it receives a signal death, but ^Z is stopping the job and putting it in limbo. If it hurts, don't do it (or use "fg" or "bg" to let it finish).

Show 15 quoted lines

> > So what's going on is that github.com is not returning a non-existent
> > repo error; it's prompting for a username/password, as _if_ the
> > repository exists.  That's presumably to prevent disclosing
> > information as to whether or not a private repository exists or not.
> 
> I agree with you there. Coincidentally speaking, why does a username
> warrants a prompt from git, is simply beyond me. I mean, that is
> certainly the more far-fetched reasoning of implementation I've read
> in a long long time.
> 
> Can you git-clone a user? What about the user's settings? What about
> the remainder its gpg tokens and so forth? In other words, if a user's
> repo is not found, why even prompting for a username? The latter, that
> is, the user's repo, is redundant,  when the prompt is clearly asking
> for a username, and not a repo.

Huh? GitHub cannot tell you whether you have access to a repository (or, for privacy reasons of the owner of the hypothetical repository, whether a repository of that name might exist) unless you authenticate. So it returns an HTTP 401. Your authentication in this case requires a username and password. Git asks for the username first, then the password.

Is there something else you think GitHub should be returning there? Or something else you think Git should do with an HTTP 401?

-Peff