Re: [PATCH] filter-branch: Grok special characters in tag names

Brandon Casey [off-list ref] writes:

Junio complained that my initial version of this was fragile which has
similarities with the above. Initially, I was blindly changing the first line
to contain "object...", second line to "type...", etc.

Was it more about not limiting the munging to only the header part?  In
any case, I think what Hannes has in the patch is fine (although I did not
look the lines that follow outside the context).

Would something like the following be equivalent _and_ clearer? Emphasis
on "and" because both are necessary, not because I strongly feel it to
be so.

I was bitten by a/i/c followed by literal text that behave differently
with various implementations of sed, and learned to stay away from the
construct long time ago.  Things might have gotten better these days, but
old habit and gut-reaction is hard to shake off.

Junio C Hamano wrote:

Brandon Casey [off-list ref] writes:

quoted

Junio complained that my initial version of this was fragile which has
similarities with the above. Initially, I was blindly changing the first line
to contain "object...", second line to "type...", etc.

Was it more about not limiting the munging to only the header part?

No. I originally had something like

   1c\object $new_sha1
   2c\tag commit
   ...

blindly changing line one to "object ...", line two to "tag ..." etc.
That aspect is what you commented about. So it would have modified the
proper parts of a well-formed tag.

I took your comments to be concerned with future proofing or dealing
with a corrupt/flawed tag (allowing the flaws to propagate so mktag
would error out), but you didn't state that explicitly.

You also educated me about addresses like 1,/regex/ which was used to limit
the munging to only the header part.

In
any case, I think what Hannes has in the patch is fine (although I did not
look the lines that follow outside the context).

That's fine.

-brandon