linux-kernel - Re: [ 000/103] 3.10.3-stable review

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]

Message-ID: <CAMuHMdX3783c_HcB6eVJ5Tn-n8DVmgSi9F0LtYBZUk67HY9EcQ@mail.gmail.com>
Date:	Thu, 25 Jul 2013 11:52:53 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"gregkh@...uxfoundation.org >> Kroah-Hartman, Greg" 
	<gregkh@...uxfoundation.org>, Shuah Khan <shuah.kh@...sung.com>,
	Shuah Khan <shuahkhan@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [ 000/103] 3.10.3-stable review

On Wed, Jul 24, 2013 at 7:46 PM, Steven Rostedt <rostedt@...dmis.org> wrote:
> On Wed, 2013-07-24 at 10:24 -0700, Linus Torvalds wrote:
>> On Wed, Jul 24, 2013 at 10:16 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
>>  - "git apply" is actually also designed to be a *replacement* for
>> "patch". In particular, you can use it outside a git repository,
>
> OK, this makes more sense.
>
>> exactly like you'd use the standard "patch" program. Except unlike the
>> standard "patch" program, "git apply" doesn't accept fuzz by default
>> (which to me is a huge deal - I hate how "patch" tries to apply stuff
>> that clearly isn't valid any more) and also knows about things like
>> file modes and renames etc.
>
>> That second part is something not enough people use, and when I make
>> patches and tar-balls I still generate the old-style non-rename
>> patches etc for that reason. But basically the command is designed to
>> also be used in non-git environments, so the "standard usage" is very
>> much not the "involve git details" behavior.
>
> I just find it funny to use git outside of a git environment. Perhaps
> "git apply" should have another name? "pit"?

alias pit="git apply"?

Hmm, I never used "git apply". I more find myself using plain patch if
"git am" doesn't want to take a patch due to the fuzz. Is there a fuzz
parameter for "git am"? Is this "-C 2" or "-C 1"?

>> Most "true git" workflows end up using "git am" (or, better yet, "git
>> pull" etc) to apply patches, which obviously not only does the --index
>> thing, but also applies the changelog etc.
>
> I'm still somewhat old school, and my workflow uses git + quilt a bit. I
> do a bunch of changes, then I do:
>
> git diff > foo.patch
> patch -p1 -R < foo.patch
> quilt import foo.patch
> rm foo.patch

git commit -a

> And save off those changes to another time. When I get back to the
> patch, I do:
>
> quilt push
> <make final fixes>
> quilt refresh
> quilt pop

git commit -a --amend

> git apply --index < patches/foo.patch
>
> Sometimes I just leave off the pop and apply to do a git commit -a, but
> then when I do a quilt pop I need to do a "git reset --hard" to reset
> things. Having the patch in quilt gives me a nice record of what I did,
> instead of searching through git history.
>
> Note, I do know about git quiltimport, but my quilt queue contains lots
> of debug patches and things that are still pending (I modify the series

git rebase -i

My git "queue" contains 85 commits, some of them are 4 years old.
I commit almost everything I do, and rework it until it's ready for submission.

> file a lot). What would help is to add an option to git quiltimport that
> will limit the number of patches it imports.
>
> git quiltimport -c 1

vi series
go to the first patch you don't want to apply
dG
:w
CTRL-Z
run quiltimpirt
fg
u
:w

I never regretted the move from quilt (+ git) to git. To me quilt feels like
having the disadvantages of "git rebase", without having its advantages.

The only feature from quilt I miss is the ability to put comments (mostly
markers "for x.y", and separators and blank lines) in the series file.
Managing the order of patches (and only that) in a quilt series file is still
a bit more user-friendly than in a "git rebase -i" session.

Guess I should start using "git commit --allow-empty" to add markers?
Hmm, probably git will complain again and again about empty commits
when rebasing?

Andrew: Anything else why you're still using quilt?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
--
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/