From: Stephen Hemminger <stephen@networkplumber.org>
To: "Eric Sun (ericsun2)" <ericsun2@cisco.com>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: bridge-utils: request to fix git tags
Date: Fri, 12 Dec 2025 15:14:01 +0900 [thread overview]
Message-ID: <20251212151401.3b3228c4@stephen-xps.local> (raw)
In-Reply-To: <161B0C34-1F18-4010-B89B-738DA12F77DC@cisco.com>
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.
prev parent reply other threads:[~2025-12-12 6:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-12 2:26 bridge-utils: request to fix git tags Eric Sun (ericsun2)
2025-12-12 4:00 ` Stephen Hemminger
2025-12-12 6:14 ` Stephen Hemminger [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251212151401.3b3228c4@stephen-xps.local \
--to=stephen@networkplumber.org \
--cc=ericsun2@cisco.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox