linux-kernel - Re: [git pull] drm-fixes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 26 Jan 2009 14:08:33 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Sam Ravnborg <sam@...nborg.org>
cc:	Dave Airlie <airlied@...il.com>, Dave Airlie <airlied@...ux.ie>,
	dri-devel@...ts.sf.net,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>
Subject: Re: [git pull] drm-fixes

On Mon, 26 Jan 2009, Sam Ravnborg wrote:

> > 
> > Well I'm not 100% sure what happened for this patch, I suspect,
> > jbarnes sent patch a week
> > or two ago, it misapplied against the tree I had currently when
> > applied with git-am, it didn't work so I hand
> > applied the patch with patch and then did git commit
> > --author="jbarnes" as he did write it, I just munged it.
> > 
> > Now I'm unsure how I should best handle this, in a world where I can
> > devote a lot more time to
> > maintaining this, I would sent Jesse a mail saying, rebase, he'd reply
> > with a rebase and I'd apply it,
> > however I generally find it easier to just fix this stuff up on the
> > run as its synchronous. Should
> > I be specifying a date somewhere in the commit message?
> 
> My simple way to deal with this is to:
> 
> 0) save the mail
> 1) fix subject and changelog and add my Signed-off-by:
> 2) apply the patch somehow
> 3) replace the origianl patch in the (saved) mail
> 4) git reset --hard (or patch -p1 -R < saved-mail)
> 5) git am <saved mail>
> 
> There must be easier ways to do so I think.

Um. Yes. Something like

	git am -s -C1

which ends up requiring just a single line of context for the patch to 
apply, exactly like the GNU 'patch' program.

The difference being that GNU patch does that incredibly broken thing by 
default, and makes it easy to apply a patch that was already applied quite 
by mistake, because it still works. Git will require you to say explicitly 
that it's ok to have just a single line of context.

Anyway, on its own I wouldn't have reacted - sure, you can just do the 
whole "use patch and then commit as another user" and the times will be 
odd, but the *big* issue with Dave's pull-request was that there were 
multiple cases of just clearly lost information.

In other words, I don't care about the dates. I don't care _how_ you do 
your git commits. And I don't even care if you use the broken "patch" 
command that accepts random line noise as a patch, as long as you check it 
later.

But I _do_ care when it looks like somebody is using a bad process that 
clearly isn't working, and that clearly is dropping things on the floor. 
If it's a "odd things happens very occasionally because I had to use a 
special sequence for it", that's fine.

So when 3 out of 8 patches were somehow missing information (two without 
sign-offs, and the third that had a sign-off but was obviously also done 
by the odd sequence that dropped the timestamp), that's no longer just 
some occasional issue and is a more endemic process problem.

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/