git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 0/3] treewide: migrate from legacy utime.h to utimensat

From
WYWeijie Yuan <wy@wyuan.org>
Date
Aug 24, 2026, 15:33 UTC
Message-ID
<aoxkQHCGJENGxV2I@wyuan.org>
In-Reply-To
<xmqqfr04thhe.fsf@gitster.g>
On Sun, Aug 23, 2026 at 06:49:49PM -0700, Junio C Hamano wrote:
Show 18 quoted lines
> Weijie Yuan <wy@wyuan.org> writes:
> 
> >> We know Johannes well enough to trust that his patches were sent
> >> with sufficient due diligence.  So...?
> >
> > <xmqqzeyeujde.fsf@gitster.g>:
> >> If work submitted under a DCO later turns out to be based on
> >> something we cannot legally use, the submitter may of course be in
> >> trouble, but we would also need to bear the cost of ripping it out;
> >> the later we discover the problem, the more substantial the effort
> >> necessary to deal with the fallout will be.
> >
> > What I meant is that you said we should be wary of content that might
> > carry legal risks,...
> 
> I am not sure what your point is.  Is there any part in "we trust
> Dscho well enough to trust that he sent them with sufficient due
> diligence" that was hard for you to understand?

Sorry, I think I failed to make my actual question clear in my previous replies.

I do understand, and agree with, your point that you trust Johannes to have submitted his patches with sufficient due diligence. I was not trying to question Johannes or your trust in him.

What I was trying to understand is how that fits with the particular DCO concern being discussed here.

You pointed out that if something submitted under the DCO later turns out to be based on material we cannot legally use, the project also bears the cost of removing it, and that the fallout becomes worse the later such a problem is discovered.

As I understand brian's concern, if a significant amount of a contribution is generated by an AI tool, there may be uncertainty over whether the submitter can make the DCO certification with sufficient confidence.

That is why Johannes's existing commits with an Assisted-by trailer came to mind. I am not claiming that those commits necessarily contain AI-generated content of the kind brian is concerned about; I do not know what the assistance actually consisted of.

But if the disclosed assistance did involve generated content of that kind, wouldn't the same DCO question arise? And if we do not know whether it did, isn't that the sort of question that, following your point above, would be better clarified sooner rather than later?

At the same time, I can also see the point behind your:
"if you use one, do not tell us" ;-)

Thinking about it from that angle also makes me wonder about Assisted-by trailers themselves. If I understand the point behind "if you use one, do not tell us" correctly, then perhaps we should simply not encourage Assisted-by: LLM trailers, since such a trailer explicitly records the very fact that we might prefer the project not to be told about.

Of course, I am simply worried that an Assisted-by trailer might create some legal risk. I am not a lawyer, though, so I do not know whether that concern is actually well-founded.

On the other hand, I can also understand why the kernel community made a different trade-off and prefers disclosure. Knowing that a tool was involved gives the maintainer additional information, and the maintainer can then decide according to their own judgment whether that information should affect how the patch is handled. (possibly there are other reasons)

That was what I was trying, rather unsuccessfully, to get at before. I am sorry that my earlier replies made it sound as though I was singling out Johannes as a problematic case.

Sorry again for the confusion and the noise.

Thanks, Weijie

Previous: Weijie YuanNext: Junio C Hamano
Message 15 of 19 in “treewide: migrate from legacy utime.h to utimensat”
  1. 0/3 treewide: migrate from legacy utime.h to utimensatAlexey Samsonov via GitGitGadget, Aug 21, 2026
  2. 1/3 compat/posix: introduce utimensat(2) wrapperAlexey Samsonov via GitGitGadget, Aug 21, 2026
  3. 2/3 treewide: use utimensat(2) instead of legacy utime(3p)Alexey Samsonov via GitGitGadget, Aug 21, 2026
  4. 3/3 compat/posix: drop legacy <utime.h> header and shimsAlexey Samsonov via GitGitGadget, Aug 21, 2026
  5. Junio C HamanoAug 21, 2026
  6. brian m. carlsonAug 22, 2026
  7. Junio C HamanoAug 22, 2026
  8. brian m. carlsonAug 22, 2026
  9. Junio C HamanoAug 23, 2026
  10. Weijie YuanAug 23, 2026
  11. Junio C HamanoAug 23, 2026
  12. Weijie YuanAug 23, 2026
  13. Junio C HamanoAug 24, 2026
  14. Weijie YuanAug 24, 2026
  15. Weijie YuanAug 24, 2026
  16. Junio C HamanoAug 24, 2026
  17. Junio C HamanoAug 24, 2026
  18. Weijie YuanAug 24, 2026
  19. Oswald BuddenhagenAug 24, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.