threads / discuss / 51043

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

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

## tl;dr

2 messages between May 6, 2019 and May 6, 2019.

replies: 1people: 2as markdown or json

Palauzov, Dilyan· May 6, 2019, 18:19 UTC · lore
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· May 6, 2019, 23:31 UTC · re: Palauzov, Dilyan · lore

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

On Mon, May 06 2019, Palauzov, Dilyan wrote:
Show 8 quoted lines
> 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).

← back to recent threads