Re: [PATCH v10 0/5] [GSoC] remove_subtree(): reimplement using iterators

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 20, 2017, 03:23 UTC
Message-ID: <xmqqk26fahjn.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <1492607652-36341-1-git-send-email-bnmvco@gmail.com>

Daniel Ferreira <bnmvco@gmail.com> writes:

> I do not know if "queuing" meant I did not have to change this series
> any further (specially after Stefan's "ok"), but anyway, this series
> applies Junio's corrections back from v9, that were mostly regarding
> commit messages or style. I hope I got them right.

Queuing merely means that I queued the series on its own topic branch and merged it to 'pu', which is a bit more (but not much more) permanent place than the list archive. It does not mean anything more---specifically, it does not mean that it is now cast in stone. It does not mean it will appear in the next release, either.

If you and others are happy with the state of the commits recorded, we may then merge the topic to 'next' and then to 'master'. But in the meantime, if there are things that you are not exactly happy in the series (e.g. you found a better way to approach the issue you tackled, you noticed that you didn't fully address the review comments, etc.) you are welcome to further polish your topic by sending out replacements.

> The only point I was in doubt was about Michael's signoff. Actually, he
> gave it not regarding the snippet for the new dir_iterator_advance()
> logic, but to a small piece of actual code he wrote on the new dir
> iterator test helper[1].

If part of your patch contains his code more or less verbatim, then it is the right thing to do to have his sign-off. For that part you are relaying his patch, so he signs it off first, signaling that he wrote it and he has the authority to release it to the project, and then you sign it off, signaling that you have the authority to relay it to the project (see DCO in Documentation/SubmittingPatches).

> I also didn't get whether I myself should have renamed t0065 to t0066
> given the other queued patch.

I would have expected you to move it over to t0066, as I'd have to rename it myself otherwise. There is no "skipping" of a number in the result, as this series comes later than the one that adds t0065.

Having said that, there is no need to resend the series if the only change necessary on top of v10 were renaming t0065 to t0066.

Thanks.