Issue with commit a2b26ff "fsck: convert gitmodules url to URL passed to curl"

Issue with commit a2b26ff "fsck: convert gitmodules url to URL passed to curl"

[Arno Gourdol]

Hi,

I have run into an issue that is preventing me from pushing commits to my GitHub repo. I believe the problem can be tracked down to this change:

https://github.com/git/git/commit/a2b26ffb1a81aa23dd14453f4db05d8fe24ee7cc

This change introduced stricter validation and checking of the .gitmodules file.

The problem is that I had an invalid URL in my .gitmodules file (an extra "/" in "http://“):

```
[submodule "packages/website/assets/tecendil-js"]
    path = packages/website/assets/tecendil-js
    url = https:///github.com/arnog/tecendil-js.git
    branch = master
```

However, I cannot commit a fix to this, as it gets rejected because the current .gitmodules is invalid. As a result I can no longer push commits to my repo.

Any suggestion on how to work around this?

(PS: I have attempted to contact GitHub about this, but haven’t heard back)

Best,
Arno.

Re: Issue with commit a2b26ff "fsck: convert gitmodules url to URL passed to curl"

[Jeff King]

On Mon, May 11, 2020 at 11:02:24AM -0700, Arno Gourdol wrote:

> This change introduced stricter validation and checking of the .gitmodules file.
> 
> The problem is that I had an invalid URL in my .gitmodules file (an extra "/" in "http://“):
> 
> ```
> [submodule "packages/website/assets/tecendil-js"]
>     path = packages/website/assets/tecendil-js
>     url = https:///github.com/arnog/tecendil-js.git
>     branch = master
> ```

Yeah, I agree that would be blocked by the recent fsck changes you
found.

> However, I cannot commit a fix to this, as it gets rejected because
> the current .gitmodules is invalid. As a result I can no longer push
> commits to my repo.

Was the broken .gitmodules already pushed up? If so, then the push
fixing it shouldn't need to send the bad object, and should be allowed.
Though you need to make sure you aren't pushing up any intermediate
trees with the broken state, either (i.e., you can't push up the fix on
top of some other changes; the fix has to come first).

If it wasn't already pushed up, then you should be able to fix via "git
rebase -i" or similar. That will rewrite history, but the history hasn't
been shared with anyone else by pushing, it shouldn't be a big deal.

> (PS: I have attempted to contact GitHub about this, but haven’t heard back)

Hopefully one of the suggestions above should lead to a resolution. But
in the worst case they can relax the fsck restrictions temporarily to
get a fix pushed up.

-Peff