On Wed, Jan 16, 2013 at 2:37 AM, Junio C Hamano <gits...@pobox.com> wrote:
> Adam Spiers <g...@adamspiers.org> writes:
>> On Mon, Jan 14, 2013 at 10:23 PM, Junio C Hamano <gits...@pobox.com> wrote:
>>> * as/check-ignore (2013-01-10) 12 commits
>>> (merged to 'next' on 2013-01-14 at 9df2afc)
>>> + t0008: avoid brace expansion
>>> + add git-check-ignore sub-command
>>> + setup.c: document get_pathspec()
>>> + add.c: extract new die_if_path_beyond_symlink() for reuse
>>> + add.c: extract check_path_for_gitlink() from treat_gitlinks() for reuse
>>> + pathspec.c: rename newly public functions for clarity
>>> + add.c: move pathspec matchers into new pathspec.c for reuse
>>> + add.c: remove unused argument from validate_pathspec()
>>> + dir.c: improve docs for match_pathspec() and match_pathspec_depth()
>>> + dir.c: provide clear_directory() for reclaiming dir_struct memory
>>> + dir.c: keep track of where patterns came from
>>> + dir.c: use a single struct exclude_list per source of excludes
>>> Add a new command "git check-ignore" for debugging .gitignore
>> The above is v4 plus the "t0008: avoid brace expansion" fix. v4 is
>> slightly outdated and not quite the right version to merge to 'next'.
> The "What's cooking" is a report of what _has_ already happened. I
> would have appreciated if you said the above _before_ this happened.
I did, 8 days ago in the link which you just trimmed from your reply:
The additional issues with t0008 were discovered after I posted v4, as
reflected in last Wednesday's "What's cooking" (#04):
"The test it adds seems to break under dash.
Expecting a reroll or fixup."
I assumed that for brevity you had deliberately omitted mentioning the
outstanding dir.exclude_list_group[EXC_CMDL].el encapsulation
issue linked above, so I thought we were aligned at this point.
However I see now that you changed the status to an intention to merge
this to 'next' in last Friday's "What's cooking" (#05). That gave me
a window of under 72 hours in which to reiterate the need for a final
re-roll. Unfortunately with other commitments and illness over the
weekend, I didn't catch this in time.
However, the damage is very small:
>> I'll post a v5 re-roll as per:
> Now the series is in 'next', it is too late to _replace_ it X-<.
> Could you instead make an incremental updates on top? That way, we
> do not have to re-review the whole thing; we only need to review the
> changes relative to the old one, making sure that the fixes in the
> updates are better than the v4 version.
Sure, that's easy to do. It'll be a single small patch very similar
to this one:
minus the superfluous printf() debug statements. I'll do that now.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html