On Wed, Sep 03, 2014 at 04:14:34PM -0700, Junio C Hamano wrote:
> > The main advantage of the "tag" field is that it is machine-readable,
> > and that your verification process can check that "git verify-tag
> > v2.1.0" actually returns a tag that says "tag v2.1.0". But I do not
> > think we do th
Jeff King writes:
> This is a bit of an aside, but why do we have the "tag" line in the tag
> object in the first place?
http://thread.gmane.org/gmane.linux.kernel/297998/focus=1410
> It is part of the object contents, and therefore is part of the
> signature (which the refname is not). That's
On Sun, Aug 31, 2014 at 03:46:42PM -0700, Junio C Hamano wrote:
> If "git fsck" were a tool to validate that the objects and refs are
> in line with how "git-core" plumbing and Porcelain toolset uses the
> underlying Git data model, it makes sense to insist a tag has a name
> that is suitable for
On Tue, Sep 02, 2014 at 11:41:11AM -0700, Junio C Hamano wrote:
> > Personally, I think the cover letter is a good place for such things.
>
> Yeah, and I saw it explained in the cover. It looked somewhat out
> of place to see it duplicated only for this patch in the 6 patch
> series and I was wo
Jeff King writes:
> On Thu, Aug 28, 2014 at 02:25:16PM -0700, Junio C Hamano wrote:
>
>> Johannes Schindelin writes:
>>
>> > We inspect commit objects pretty much in detail in git-fsck, but we just
>> > glanced over the tag objects. Let's be stricter.
>> >
>> > This work was sponsored by GitHub
Jeff King writes:
> Hmm. But that is because "git tag" always makes one type of tag: one in
> which the "tag" field is the same as the refname in which we store it.
> So the name must be a valid refname there to meet the ref storage
> requirement, and therefore the tag name must, too.
>
> But is
On Thu, Aug 28, 2014 at 02:36:22PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> >> + if (check_refname_format(buffer, REFNAME_ALLOW_ONELEVEL))
> >> + ret = error_func(&tag->object, FSCK_ERROR, "invalid 'tag' name:
> >> %s", buffer);
> >> + *eol = '\n';
> >
> > I actually
On Thu, Aug 28, 2014 at 02:25:16PM -0700, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > We inspect commit objects pretty much in detail in git-fsck, but we just
> > glanced over the tag objects. Let's be stricter.
> >
> > This work was sponsored by GitHub Inc.
>
> Is it only this co
Junio C Hamano writes:
>> +if (check_refname_format(buffer, REFNAME_ALLOW_ONELEVEL))
>> +ret = error_func(&tag->object, FSCK_ERROR, "invalid 'tag' name:
>> %s", buffer);
>> +*eol = '\n';
>
> I actually think this check is harmful.
Let me take this one back; we do a moral equ
Johannes Schindelin writes:
> We inspect commit objects pretty much in detail in git-fsck, but we just
> glanced over the tag objects. Let's be stricter.
>
> This work was sponsored by GitHub Inc.
Is it only this commit, or all of these patches in the series?
Does GitHub want their name sprinkle
We inspect commit objects pretty much in detail in git-fsck, but we just
glanced over the tag objects. Let's be stricter.
This work was sponsored by GitHub Inc.
Signed-off-by: Johannes Schindelin
---
fsck.c | 88 +-
1 file changed,
11 matches
Mail list logo
