[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7vsjm2870k.fsf@alter.siamese.dyndns.org>
Date: Sat, 05 Nov 2011 16:49:15 -0700
From: Junio C Hamano <junio@...ox.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: "Ted Ts'o" <tytso@....edu>, Shawn Pearce <spearce@...arce.org>,
git@...r.kernel.org,
James Bottomley <James.Bottomley@...senpartnership.com>,
Jeff Garzik <jeff@...zik.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-ide@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git patches] libata updates, GPG signed (but see admin notes)
Linus Torvalds <torvalds@...ux-foundation.org> writes:
> So I'd really like some way to not see it.
>
> Ted suggested a NUL character in the commit message in front of the
> "hidden content". What do you think?
You do not have to resort to NUL; we could just stuff whatever you do not
need to see but needs to be left *intact* in the new header fields just
like the embedded GPG signatures are stored in signed commits.
By the time the integrator is presented the merge commit template, we
would have:
1. The merge title (e.g. "Merge tag for-linus of git://.../rusty.git/");
2. Payload of the signed tag (or just "annotated tag"), which is used to
convey meaningful topic description from the lieutenant;
3. The signature in the tag, if the tag is not just merely annotated, but
is signed;
4. The output from GPG verification of the above (only when 3. is
available); and
5. The traditional "merge summary", if merge.log is enabled.
The 10-patch series I sent earlier appends 2 and 3 with "tag:" prefix and
4 with "# " prefix in the commit log template, but it does not have to be
that way. We could arrange things so that we put only 1, 2, 4 (still with
"# " prefix because this is meant to help you verify the authenticity, not
for later third-party audit, and to be stripped away with stripspace
before the commit is made) and 5 in the commit log template, and the
original signed tag contents (only when the tag is signed, not merely
annotated) in a separate file MERGE_SIG in $GIT_DIR/ next to MERGE_MSG,
and teach "git commit" to pick it up and stuff it in a new header field.
That way, the integrator can use the message 2 for the commit log message
and is free to typofix it, without breaking later third-party audit which
would use what is taken literally from the signed tag and stored in the
new header field, because the integrator's editor would never touch the
latter.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists