On Tue, Oct 22, 2019 at 02:11:22PM +0200, Vegard Nossum wrote:
>
> As I wrote in there, we could already today start using
>
> git am --message-id
>
> when applying patches and this would provide something that a bot could
> annotate with git notes pointing to lore/LKML/LWN/whatever. I think t
On Fri, Oct 18, 2019 at 06:50:51PM +0200, Vegard Nossum wrote:
> I started out using this approach, but I changed it because the
> implementation was a bit annoying: 'git am' runs 'git mailsplit',
> which just splits the email into two parts:
>
> 1) headers, changelog, and diffstat;
> 2) diff and
On Fri, Oct 18, 2019 at 04:27:48PM +0200, Vegard Nossum wrote:
> commit ac30b08065cd55362a7244a3bbc8df3563cefaaa
> tree 8f09d9d6ed78f8617b2fe54fe9712990ba808546
> parent 108b97dc372828f0e72e56bbb40cae8e1e83ece6
> author Vegard Nossum 1570284959 +0200
> committer Vegard Nossum 1571408340 +0200
> g
On Thu, Oct 17, 2019 at 04:01:33PM +0200, Vegard Nossum wrote:
>
> In your example, couldn't Darrick simply base his xfs work on the latest
> xfs branch that was pulled by Linus? That should be up to date with all
> things xfs without having any of the things that made Linus's tree not
> work for
On Thu, Oct 17, 2019 at 02:23:58PM +0200, Vegard Nossum wrote:
> Of course, this relies strongly on actually having (correct) sha1
> references to previous versions inside the changelog. In my original
> idea, this reference would only appear inside the merge commit that
> binds the patchset togeth
On Mon, Aug 26, 2019 at 10:27:00PM -0400, Jeff King wrote:
> > cannot open test-results/p5302-pack-index.subtests: No such file or
> > directory at ./aggregate.perl line 153.
>
> Implies that we're trying to _write_ to it, and that the problem is that
> test-results doesn't exist. That should be
On Mon, Aug 26, 2019 at 04:50:13PM -0400, Jeff King wrote:
> On Sun, Aug 18, 2019 at 12:03:17PM -0400, Theodore Y. Ts'o wrote:
>
> > I was trying to run "make profile" on the master branch (commit
> > 5fa0f5238b: "Git 2.23") and it died in the
> >
I was trying to run "make profile" on the master branch (commit
5fa0f5238b: "Git 2.23") and it died in the
$(MAKE) PROFILE=GEN perf
dies with:
cannot open test-results/p5302-pack-index.subtests: No such file or
directory at ./aggregate.perl line 153.
I presume that's becuase th
On Sun, Jul 28, 2019 at 09:23:18AM +0200, Matthias Beyer wrote:
>
> So what I am looking for is tools to automate contributor and maintainer
> workflow, especially:
>
> 1) Repliying to each emailpatch of a set of patches with
>"Reviewed-by: " (or other trailers)
>
>Szenario: I see a patc
On Thu, Jul 19, 2018 at 09:08:08PM -0400, Jeff King wrote:
> Ditto for sprintf, where you should _always_ be using at least xsnprintf
> (or some better tool, depending on the situation). And for strncpy,
> strlcpy (or again, some better tool) is strictly an improvement.
Nitpick: this may be true
On Fri, Jul 06, 2018 at 04:21:47PM -0700, frede...@ofb.net wrote:
> I don't think that it's really important to find a "best" ordering for
> commands or glossary terms; it's more a matter of finding someone who
> is willing to take responsibility for choosing a reasonable ordering.
> Presumably the
On Tue, Jun 12, 2018 at 09:12:19PM +0200, Peter Backes wrote:
> This incorrect claim is completely inverting the logic of Art. 17.
>
> The logic is clarly that if ANY of lit (a) to (f) is satisfied, the
> data must be deleted.
>
> It is not necessary for ALL of them to be satisfied.
>
> In part
On Sat, Jun 09, 2018 at 11:50:32PM +0100, Philip Oakley wrote:
> I just want to remind folks that Gmane disappeared as a regular list because
> of a legal challenge, the SCO v IBM Unix court case keeps rumbling on, so
> clarifying the legal case for:
> a) holding the 'personal git meta data', and
>
On Fri, Jun 08, 2018 at 08:26:57AM +0200, Peter Backes wrote:
>
> If you run a website where the world can access a repository, you are
> responsible for obeying the GDPR with respect to that repository. If
> you receive a request to be forgotten, you have to make sure you stop
> publishing tha
On Fri, Jun 08, 2018 at 01:21:29AM +0200, Peter Backes wrote:
> On Thu, Jun 07, 2018 at 03:38:49PM -0700, David Lang wrote:
> > > Again: The GDPR certainly allows you to keep a proof of copyright
> > > privately if you have it. However, it does not allow you to keep
> > > publishing it if someone e
On Mon, Jun 04, 2018 at 12:16:16AM +0200, Peter Backes wrote:
>
> Verifying the commit ID by itself wouldn't be any less efficient than
> before. Admitteldly, it wouldn't verify the author and authordate
> integrity anymore without additional work. That would be some overhead,
> sure, and could
On Sun, Jun 03, 2018 at 10:52:33PM +02h00, hPeter Backes wrote:
> But I will take your message as saying you at least don't see any
> obvious criticism leading to complete rejection of the approach.
If you don't think a potential 2x -- 10x performance hit isn't a
blocking factor --- sure, go ahea
On Sun, Jun 03, 2018 at 09:24:17PM +0200, Peter Backes wrote:
>
> He said: It would be a tyranny of lawyers.
>
> Let's not have a tyranny of lawyers. Let us, the engineers and hackers,
> exercise the necessary control over those pesky lawyers by defining and
> redefining the state of the art in
On Sun, Jun 03, 2018 at 07:46:17PM +0200, Peter Backes wrote:
>
> Let's be honest: We do not know what legitimization exactly in each
> specific case the git metadata is being distributed under.
It seems like you are engaging in something even more dangerous than a
hardware engineering pretendin
19 matches
Mail list logo
