patchdoc: filter-branch does not require re-export of vars

The function `set_ident` in `filter-branch` exported the variables GIT_(AUTHOR|COMMITTER)_(NAME|EMAIL|DATE) at least since 6f6826c52b in 2007. Therefore the filter scripts don't need to re-eport them again.

Signed-off-by: Andreas Heiduk <asheiduk@gmail.com>
---
 Documentation/git-filter-branch.txt | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

On Fri, May 26, 2017 at 07:36:54PM +0200, Andreas Heiduk wrote:

Some old shells keep separate values for the internal and exporter versions of variables. I.e., this:

  foo=one
  export foo
  foo=two

would continue to export $foo as "one", even though it is "two" inside the script.

However, I think POSIX mandates the behavior you'd expect. And the only shell I know that misbehaves in this way is Solaris /bin/sh, which we have already declared too broken to support. According to

  https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Limitations-of-Builtins.html#export

it sounds like there are some other antique shells which may do the same (it doesn't cover this case explicitly, but the "coexist" cases it mentions are likely to behave in this way).

At this point, I'd be inclined to remove the text as you suggest and either make a small note at the bottom of the page, or just omit it entirely and assume that anybody on an old non-POSIX shell can fend for themselves.

-Peff

Jeff King <peff@peff.net> writes:

Yup, that sounds like a grandfather's war story at this point, though ;-)

Sounds good to me.  Thanks.

On Fri, May 26, 2017 at 2:37 PM, Jeff King <peff@peff.net> wrote:

Off-topic, but where is this explicitly documented?

On Sun, May 28, 2017 at 09:35:30PM -0400, Samuel Lijin wrote:

I couldn't find a place that mentioned it explicitly, but POSIX defines the concept as "the export attribute" of the variables. Which implies to me that the bit is tied to the variable itself, not its value.

It also says that the flag is cleared when a variable is unset, so:

  foo=one
  export foo
  sh -c 'echo $foo should be one'
  unset foo
  foo=two
  sh -c 'echo $foo is not exported'

That could potentially affect somebody writing a filter-branch snippet, but presumably if they are using "unset" they know what they're doing.

-Peff

Samuel Lijin <sxlijin@gmail.com> writes:

One link I had readily available was

  https://public-inbox.org/git/7vei5qtnc5.fsf@alter.siamese.dyndns.org/

but there may be older discussions that were the actual process of our officially having "written its /bin/sh off as broken and unusable" if you dig further in the list archive.

On Mon, May 29, 2017 at 01:27:45PM +0900, Junio C Hamano wrote:

Ah, I had taken Samuel's question as "where is the POSIX behavior documented". :)

The link above is a good explanation of the $() problem on Solaris. It also doesn't do ${parameter#word}. I couldn't find a specific moment of outlawing that /bin/sh, but there are several mentions of problems with it going back to the beginning. Here's one from 2007:

  http://public-inbox.org/git/7vabt9sasl.fsf@assigned-by-dhcp.cox.net/

We had already given up on it by then.

I don't think there's anything in CodingGuidelines (though t/README does call it "broken"), though it explicitly endorses $(), which rules out Solaris /bin/sh.

I think we found in the last year or two that there are some old versions of ksh that don't like our scripts (definitely ksh88, and maybe ksh93?). Some light reading for the curious:

  http://public-inbox.org/git/CALR6jEhviK9KZxR6R6xzkZ5EAO-RjWj3xYah_DOSDXhEjYsT-A@mail.gmail.com/

  http://public-inbox.org/git/CALR6jEjWjJA0X2qXsxqObqc_yxrgX87LYf8cmJ0MmJFF6PkmTQ@mail.gmail.com/

  http://public-inbox.org/git/xmqqinxt3kwq.fsf@gitster.mtv.corp.google.com/

The problems are around backslash-escaping, signal exit codes, and doubled parentheses. There are some patches, but I think we decided not to pursue it (I couldn't find that exact decision, but it's referenced later on).

-Peff