Re: [PATCH v10 0/5] [GSoC] remove_subtree(): reimplement using iterators
- Date: Wed, 19 Apr 2017 20:23:24 -0700
- From: Junio C Hamano <gitster@xxxxxxxxx>
- Subject: Re: [PATCH v10 0/5] [GSoC] remove_subtree(): reimplement using iterators
Daniel Ferreira <bnmvco@xxxxxxxxx> 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,
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.
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.