From: Linus Torvalds <torvalds@linux-foundation.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v2 00/12] Pulling signed/annotated tags
Date: Mon, 7 Nov 2011 21:31:05 -0800 [thread overview]
Message-ID: <CA+55aFyEuuT25m00uakL66YKSpT-zjoiBreymFSbuHmtARq6yw@mail.gmail.com> (raw)
In-Reply-To: <7vsjlzyza7.fsf@alter.siamese.dyndns.org>
On Mon, Nov 7, 2011 at 9:10 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
> Eek.
>
> The mergetag stuff is a dump of "cat-file tag" so if you have a line that
> begins with "object " the parsing side (which does not exist yet) would
> have trouble. We would need to devise e.g. adding number of lines at the
> beginning, or something.
Might I suggest making it simpler still to parse?
Change "strbuf_add_lines()" to have two *different* prefixes: one for
the first line, and one for "continuation lines".
Then you can just use the same prefix if you want to - and get the
semantics you have now for that helper.
But instead of just having "mergetag" as the prefix for all the lines
copied from the merge, wouldn't it be nice and easy to have "mergetag"
as the prefix for the *first* line of each copied tag, but then have
some other tag for lines 2..n?
I think that would be *way* easier to parse, and I think something
like that could be a good generic model for any multi-line thing -
have the first line tagged, and the rest have just the continuation
marker. You don't really need to repeat the tag over and over again
each line, it just causes ambiguoity as shown by this example.
But I don't have any really strong opinions on it. I just think it's a
good idea to make it easy to parse both mechanically and
human-visually, and "number of lines" doesn't strike me as being very
human-friendly.
Linus
next prev parent reply other threads:[~2011-11-08 5:31 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-05 6:01 [PATCH 00/10] Pulling signed tag Junio C Hamano
2011-11-05 6:01 ` [PATCH 01/10] Split GPG interface into its own helper library Junio C Hamano
2011-11-05 6:01 ` [PATCH 02/10] fetch: do not store peeled tag object names in FETCH_HEAD Junio C Hamano
2011-11-05 6:01 ` [PATCH 03/10] merge: notice local merging of tags and keep it unwrapped Junio C Hamano
2011-11-05 6:01 ` [PATCH 04/10] fetch: allow "git fetch $there v1.0" to fetch a tag Junio C Hamano
2011-11-05 6:01 ` [PATCH 05/10] tests: distinguish merges of tags and commits Junio C Hamano
2011-11-05 6:01 ` [PATCH 06/10] refs DWIMmery: use the same rule for both "git fetch" and others Junio C Hamano
2011-11-05 6:01 ` [PATCH 07/10] fmt-merge-msg: avoid early returns Junio C Hamano
2011-11-05 6:01 ` [PATCH 08/10] fmt-merge-msg: package options into a structure Junio C Hamano
2011-11-05 6:01 ` [PATCH 09/10] fmt-merge-msg: Add contents of merged tag in the merge message Junio C Hamano
2011-11-05 8:43 ` Johannes Sixt
2011-11-06 6:03 ` Junio C Hamano
2011-11-05 6:01 ` [PATCH 10/10] merge: force edit mode when merging a tag object Junio C Hamano
2011-11-05 9:27 ` [PATCH 00/10] Pulling signed tag Nguyen Thai Ngoc Duy
2011-11-08 3:00 ` [PATCH v2 00/12] Pulling signed/annotated tags Junio C Hamano
2011-11-08 3:00 ` [PATCH v2 01/12] Split GPG interface into its own helper library Junio C Hamano
2011-11-08 3:00 ` [PATCH v2 02/12] fetch: do not store peeled tag object names in FETCH_HEAD Junio C Hamano
2011-11-08 3:00 ` [PATCH v2 03/12] merge: notice local merging of tags and keep it unwrapped Junio C Hamano
2011-11-08 3:00 ` [PATCH v2 04/12] fetch: allow "git fetch $there v1.0" to fetch a tag Junio C Hamano
2011-11-08 3:00 ` [PATCH v2 05/12] refs DWIMmery: use the same rule for both "git fetch" and others Junio C Hamano
2011-11-08 3:00 ` [PATCH v2 06/12] fmt-merge-msg: avoid early returns Junio C Hamano
2011-11-08 3:00 ` [PATCH v2 07/12] fmt-merge-msg: package options into a structure Junio C Hamano
2011-11-08 3:00 ` [PATCH v2 08/12] fmt-merge-msg: Add contents of merged tag in the merge message Junio C Hamano
2011-11-08 3:00 ` [PATCH v2 09/12] merge: make usage of commit->util more extensible Junio C Hamano
2011-11-08 3:00 ` [PATCH v2 10/12] merge: record tag objects without peeling in MERGE_HEAD Junio C Hamano
2011-11-08 3:00 ` [PATCH v2 11/12] commit: copy merged signed tags to headers of merge commit Junio C Hamano
2011-11-08 3:00 ` [PATCH v2 12/12] merge: force edit mode when merging a tag object Junio C Hamano
2011-11-08 4:20 ` [PATCH v2 00/12] Pulling signed/annotated tags Linus Torvalds
2011-11-08 5:10 ` Junio C Hamano
2011-11-08 5:31 ` Linus Torvalds [this message]
2011-11-08 5:37 ` Junio C Hamano
2011-11-08 21:45 ` Junio C Hamano
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=CA+55aFyEuuT25m00uakL66YKSpT-zjoiBreymFSbuHmtARq6yw@mail.gmail.com \
--to=torvalds@linux-foundation.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/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;
as well as URLs for NNTP newsgroup(s).