On Sat, Jan 13, 2018 at 5:54 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Jeff King <peff@xxxxxxxx> writes: > >> I also think this is a special case of a more general problem. FOO could >> appear any number of times in the "env" array, as a deletion or with >> multiple values. Our prep_childenv() would treat that as "last one >> wins", I think. Could we just do the same here? > > Perhaps this should be squashed into the original 4/4 instead of > being a separate patch. We'd probably want some sort of test, I > wonder? Not tested at all beyond compiling... > > -- >8 -- > Subject: [PATCH 7/4] run-command.c: don't be too cute in concatenate_env() > > Instead of relying on "sort" being stable to sort "unset VAR" > immediately before "VAR=VAL" to remove the former, just pick the > last manipulation for each VAR from the list of environment tweaks > and show them in the output. This is not enough. Imagine we have GIT_DIR=foo in parent env, then a sequence of "GIT_DIR", "GIT_DIR=foo" in deltaenv. Because we process set/unset in two separate loops, the "last one wins" rule does not see that "GIT_DIR=foo" wins over "unset GIT_DIR;". So we might print "unset GIT_DIR; GIT_DIR=foo", which is fine even if it's redundant. Except that we don't print that. The problem comes from comparing with parent env. The new var has the same value as parent env so we won't print "GIT_DIR=foo", just "unset GIT_DIR;". This is wrong. I'm tempted to just get the final child env from prep_childenv() then compare with parent env and print the differences. It will not work with Windows though, so Windows gets the old trace line without env delta. I hope some Windows contributor will jump in at some point if they want env tracing works for them too. -- Duy
