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
>>>  files.
>> 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'.
> Sigh.
> 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[0] 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

Reply via email to