# .git/config validations by (for silly errors) by git fsck

2 messages from 2019-05-06 to 2019-05-06. Participants: Palauzov, Dilyan, Ævar Arnfjörð Bjarmason.
Thread: https://gitlist.dev/t/51043

## Palauzov, Dilyan, 2019-05-06 18:19

Subject: .git/config validations by (for silly errors) by git fsck
Message-ID: <36d37bdd70fba719ecee2c5572a8b85bc9940944.camel@sit-extern.fraunhofer.de>
URL: https://gitlist.dev/e/36d37bdd70fba719ecee2c5572a8b85bc9940944.camel%40sit-extern.fraunhofer.de

```
Hello,

I added manually a remote to .git/config, but updated only the url= line, forgetting to update the fetch= line.  So two
remotes had
  fetch = +refs/heads/*:refs/remotes/origin/*

and fetching from the one or the other has overwritten origin/master.  git fsck has not helped.

Please introduce a check in git fcsk that triggers, when two different remotes share the same fetch line, or if the
fetch line does not reference the remote name.

Regards
  Дилян

```

## Ævar Arnfjörð Bjarmason, 2019-05-06 23:31

Subject: Re: .git/config validations by (for silly errors) by git fsck
Message-ID: <875zqni2ip.fsf@evledraar.gmail.com>
URL: https://gitlist.dev/e/875zqni2ip.fsf%40evledraar.gmail.com
In-Reply-To: <36d37bdd70fba719ecee2c5572a8b85bc9940944.camel@sit-extern.fraunhofer.de>

```

On Mon, May 06 2019, Palauzov, Dilyan wrote:

> I added manually a remote to .git/config, but updated only the url= line, forgetting to update the fetch= line.  So two
> remotes had
>   fetch = +refs/heads/*:refs/remotes/origin/*
>
> and fetching from the one or the other has overwritten origin/master.  git fsck has not helped.
>
> Please introduce a check in git fcsk that triggers, when two different remotes share the same fetch line, or if the
> fetch line does not reference the remote name.

Pehaps we need a 0bc8d71b99 ("fetch: stop clobbering existing tags
without --force", 2018-08-31) but for remote branches :)

There could be room for something like this in some config-lint tool,
but what you're suggesting is not an error in the general case. There's
many use-cases for having remotes with overlapping or identical fetch
refspecs, e.g. maybe you fetch the "same" repo from two different URLs,
or one is a superset of the other (and can clobber the subset).

When you remove a remote there's even a check for this, we discover if
the refspecs exclusively "belong" to it (and then remove the remote
tracking branches), not if other remotes overlap.

Whether such a check would be viable would be one thing, but it wouldn't
currently belong in git-fsck, its job is to check the object database
for sanity, but perhaps there's cases where it makes sense to expand
that (e.g. shallow/narrow clones where you want a "full" check).

```