bridge-utils: request to fix git tags

bridge-utils: request to fix git tags

[Eric Sun (ericsun2)]

Hello,

The bridge-utils git repo [1] has several tags that cause recent-ish git fsck
to fail with the missingSpaceBeforeDate error [2]. This is frustrating when
working with github, where such cosmetic errors are not ignored by default as
they are by other platforms (e.g. gitlab).

Though bridge-utils is deprecated,  I was hoping somebody with access might be
willing to fix up the tags?

I've verified that something like [3, see: "How to work around that issue..."]
address it correctly.

Thanks in advance!

[1] https://git.kernel.org/pub/scm/network/bridge/bridge-utils.git
[2] https://git-scm.com/docs/git-fsck#Documentation/git-fsck.txt-missingSpaceBeforeDate
[3] https://sunweavers.net/blog/node/36


Cisco Confidential

Re: bridge-utils: request to fix git tags

[Stephen Hemminger]

On Fri, 12 Dec 2025 02:26:02 +0000
"Eric Sun (ericsun2)" <ericsun2@cisco.com> wrote:

> Hello,
> 
> The bridge-utils git repo [1] has several tags that cause recent-ish git fsck
> to fail with the missingSpaceBeforeDate error [2]. This is frustrating when
> working with github, where such cosmetic errors are not ignored by default as
> they are by other platforms (e.g. gitlab).
> 
> Though bridge-utils is deprecated,  I was hoping somebody with access might be
> willing to fix up the tags?
> 
> I've verified that something like [3, see: "How to work around that issue..."]
> address it correctly.
> 
> Thanks in advance!
> 
> [1] https://git.kernel.org/pub/scm/network/bridge/bridge-utils.git
> [2] https://git-scm.com/docs/git-fsck#Documentation/git-fsck.txt-missingSpaceBeforeDate
> [3] https://sunweavers.net/blog/node/36
> 
> 
> Cisco Confidential

I can see if this is fixable. But sometimes old stuff has to be preserved

Re: bridge-utils: request to fix git tags

[Stephen Hemminger]

On Fri, 12 Dec 2025 02:26:02 +0000
"Eric Sun (ericsun2)" <ericsun2@cisco.com> wrote:

> Hello,
> 
> The bridge-utils git repo [1] has several tags that cause recent-ish git fsck
> to fail with the missingSpaceBeforeDate error [2]. This is frustrating when
> working with github, where such cosmetic errors are not ignored by default as
> they are by other platforms (e.g. gitlab).
> 
> Though bridge-utils is deprecated,  I was hoping somebody with access might be
> willing to fix up the tags?
> 
> I've verified that something like [3, see: "How to work around that issue..."]
> address it correctly.
> 
> Thanks in advance!
> 
> [1] https://git.kernel.org/pub/scm/network/bridge/bridge-utils.git
> [2] https://git-scm.com/docs/git-fsck#Documentation/git-fsck.txt-missingSpaceBeforeDate
> [3] https://sunweavers.net/blog/node/36
> 
> 
> Cisco Confidential

The AI answer below is correct for this.




These errors indicate malformed tag objects where the tagger line is
missing a space between the email's closing `>` and the Unix timestamp.
This is a common issue with old tags in repositories like the Linux
kernel.

**If these are upstream/historical tags** (most likely scenario for kernel work):

These are cosmetic errors in the object format—git still functions correctly. You have a few options:

1. **Ignore them** — The tags still work, this is just `fsck` being pedantic about format compliance.

2. **Suppress the warnings** by configuring git to skip this specific check:
   ```bash
   git config fsck.missingSpaceBeforeDate ignore
   git config transfer.fsckObjects false  # if you want to suppress during fetch/push too
   ```

3. **Check what the tags are**:
   ```bash
   git cat-file tag e601dc1094107999de050b7104bf01ce865fe60f
   ```
   This will show you the raw tag content so you can see the malformed line.

**If you actually need to fix them** (e.g., your own repo):

You'd need to recreate each tag:
```bash
# Get the tag name pointing to this object
git describe --tags --exact-match e601dc1094107999de050b7104bf01ce865fe60f

# Delete and recreate
git tag -d <tagname>
git tag -a <tagname> <commit-it-pointed-to> -m "message"
```

But for upstream kernel tags, the standard approach is option 1 or 2—the malformed tags are historical artifacts that everyone has, and "fixing" them would change their SHA and break reproducibility.