Re: [ 000/103] 3.10.3-stable review

[Steven Rostedt]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/