On Wed, Jul 24, 2013 at 7:46 PM, Steven Rostedt <rostedt@xxxxxxxxxxx> 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@xxxxxxxxxxx> 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@xxxxxxxxxxxxxx
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 stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html