On Sun, Jan 15, 2023 at 06:33:09PM -0500, Jeff King wrote: > On Sun, Jan 15, 2023 at 05:47:02PM -0500, Crls wrote: > > > > 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. > What I meant by blobs is in the following: Ending up with a list of directories and subdirectories, is not unusual, is actually very common really with every git-clone while fetching a non-existent repo with a git clone operation either through github or gitlab. First it comes with two (2) git, or one git instance first, then another and finally one (1) git-remote-helper instance. ps -a | grep 'git' can confirm it You'd be able to see 19159 pts/9 00:00:00 git 19160 pts/9 00:00:00 git 19161 pts/9 00:00:00 git-remote-http <defunct> 19188 pts/9 00:00:00 git 19189 pts/9 00:00:00 git 19190 pts/9 00:00:00 git-remote-http <defunct> Obviously, its <defunct processs > part was only made possible just right after and invoking a `kill -9 process id` And if you wanted to find out the leftovers behind through a `du -h <reponame>` by either by git/git-remote-helper (it doesn't really matter at this point which one out of the two may have been the culprit here): 8.0K /.git/info 4.0K /.git/objects/info 4.0K /.git/objects/pack 12K /.git/objects 64K /.git/hooks 4.0K /.git/refs/tags 4.0K /.git/refs/heads 12K /.git/refs 4.0K /.git/branches 116K /.git 120K / These are the default values. Any curl operation through git with a non-existent repo will get those values. Now. We can all proceed trying to sugar coat these leftovers behind an explanation of whatever git-remote-http is actually doing or for that matter, as I said before and without being redundant here, the git-clone processs itself, but it doesn't realyl matter, the end results are the same. Are there leftovers? You can bet on it. It may not happen — and borowwing someone else's phrasing, wording, — «instantaneous», for it's actually quite clever really, to the detriment of an end-user. I've read tibbits from gitremote-helpers(7) quote: When Git encounters a URL of the form <transport>://<address>, where <transport> is a protocol that it cannot handle natively, it automatically invokes git remote-<transport> with the full URL as thesecond argument. End quote. But it's unsettling. The whole issue. The gitremote-helper is not helping, no pun intended. Luckily for these use cases ^C and ^\ seem to be functioning. > 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). > > > > 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 -- Don't hit the keys so hard, it hurts.
