Hello Krzysztof,
On Tue, Mar 04, 2025 at 05:30:40PM +0100, Krzysztof Kozlowski wrote:
> On 04/03/2025 17:03, Uwe Kleine-König wrote:
> > On Tue, Mar 04, 2025 at 10:53:53AM +0100, Krzysztof Kozlowski wrote:
> >> On 04/03/2025 07:24, Uwe Kleine-König wrote:
> >>>> [...]
> >>>> ---
> >>>> base-commit: 0067a4b21c9ab441bbe6bf3635b3ddd21f6ca7c3
> >>>
> >>> My git repo doesn't know that commit. Given that you said your patch
> >>> bases on that other series, this isn't surprising. Please use a publicly
> >>> available commit as base parameter, otherwise you (and I) don't benefit
> >>> from the armada of build bots because they just silently fail to test in
> >>
> >> As you can easily see in the signature, this patchset was generated by
> >> b4 and such tag was added automatically. No point in stripping it even
> >> if it is not useful (life, happens).
> >
> > My request was not about stripping it, but making it useful. I don't
> > know the b4 patch sending side, but git send-email has the capability to
> > make it more useful in this scenario. I didn't check, but
> > `b4 --edit-deps` which Abel mentioned sounds about right.
> >
> > The relevant documentation for the git side is the paragraph "BASE TREE
> > INFORMATION" in git-format-patch(1).
>
> Useful how? The dependency is on the lists, so there is no base-commit
> you would know.
Have you tried to understand the part of the manpage I pointed out? It
seems to me "base-commit" has different semantics for us and only mine
is aligned to git's (and consequently b4's) meaning.
The correct base commit would have been
cd3215bbcb9d4321def93fea6cfad4d5b42b9d1d.
> And regardless of edit-deps, that base-commit tag is standard from b4,
> so what do you expect from all submitters even if this was not RFC?
I don't understand this question. I expect from submitters to pick a
publicly known commit as base no matter if the series is an RFC or who's
standard this is.
> Always base on known commit?
Yes please. The manpage isn't explicit about that but the above
referenced commit has:
The base tree info consists of the "base commit", which is a well-known
commit that is part of the stable part of the project history everybody
else works off of, and zero or more "prerequisite patches", which are
well-known patches in flight that is not yet part of the "base commit"
that need to be applied on top of "base commit" in topological order
before the patches can be applied.
> But for most of the cases this is
> irrelevant. I can have intermediate commit between linux-next tip and my
> patch, thus base-commit will be bogus for you, but it does not matter
> for the patch - it's based on linux-next.
I agree, linux-next is the base. So the respective tip of linux-next is
the right thing to pass to git format-patch --base (independent of if
it's called directly or through b4). Ideally you also drop the
irrelevant intermediate patches to make the build bots test exactly the
changes you suggest with your series. I would expect that this is the
tree you actually tested, so it shouldn't be a big hurdle.
So summarizing we have: Iff you use --base with a non-public commit, it's
useless and irrelevant. I fully agree. Our conclusion is different
though. You accept it's useless (and even request from me that I do the
same), and I asked the submitter to use --base as intended to make the
resulting information usable.
Best regards
Uwe
Attachment:
signature.asc
Description: PGP signature
