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] [day] [month] [year] [list]
Date:	Thu, 25 Jul 2013 08:47:48 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Geert Uytterhoeven <geert@...ux-m68k.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 Thu, 2013-07-25 at 11:52 +0200, Geert Uytterhoeven wrote:

> > 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"?

I have no problem using patch.

> 
> 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

I think you missed my point. I don't want to save the changes into git.
I do changes and store them away. It's much easier to search a patches
directory in git. Yeah, I can make a separate branch, but that becomes
unscalable rather quickly:


$ git branch | wc -l
296

> 
> > 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

What does that do for me?

> 
> 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.

quilt is a hell of a lot faster than git. And I deal with a bit more
than 85 commits:

$ ls patches | wc -l
313

Also, it becomes a pain to apply the same debug commits to different
branches. Sure, you can do git cherrypick, but that's all rather tedious
and awkward. quilt is much more appropriate for such a task.

> 
> > 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.

I use both heavily. I use git for a lot of my workflow. I was only
stating some of my workflow sucks with git and works better with quilt.

> 
> 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?

I use git rebase daily. But for other reasons. Clean ups, added tags,
late fixes, etc. All this before I push to next, as once I do that, I
try to avoid rebasing.

I don't think git is a replacement for quilt. To me, quilt is a very
nice complement to git.

-- Steve


--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ