From: Russell King <rmk+lkml@arm.linux.org.uk>
To: Junio C Hamano <junkio@cox.net>, Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, Petr Baudis <pasky@suse.cz>
Subject: Re: 2.6.18-mm1
Date: Sun, 24 Sep 2006 22:34:22 +0100 [thread overview]
Message-ID: <20060924213422.GD12795@flint.arm.linux.org.uk> (raw)
In-Reply-To: <7veju185j9.fsf@assigned-by-dhcp.cox.net>
Andrew - see the bottom of this message.
On Sun, Sep 24, 2006 at 11:48:26AM -0700, Junio C Hamano wrote:
> Russell King <rmk+lkml@arm.linux.org.uk> writes:
>
> > I'm just experimenting with git-apply for the forward case, and I'm
> > hitting a small problem. I can do:
> >
> > cat patch | git-apply --stat
> >
> > then I come to commit it:
> >
> > git commit -F -
> >
> > but if I just use that, _all_ changes which happen to be in the tree
> > get committed, not just those which are in the index file.
>
> That does not sound right.
You're right - I was looking at doing git-apply --stat --apply
> * "git apply --stat patch" (you do not need "cat |" there) is
> only to inspect the changes; it does not apply the change to
> your working tree. Think of it as "diffstat for git".
The "cat" bit was in there to represent the perl script piping the
patch directly into the program - there isn't a literal "cat"
command in there. 8)
> * When doing partial commits, having "git apply" to prepare
> what you want to commit in the index is less error prone
> (otherwise you would somehow need to parse the patch and find
> out what is added and what is deleted). I do not exactly
> know what you are doing in your Perl wrapper, but I suspect
> bulk of that is to figure out what is changed and run
> git-update-index on them -- you can lose all that code by
> using "git apply --index patch". Then added, removed and
> modified paths are all updated in the index.
The problem is that git apply doesn't have a "patch -R" mode - so
if I want to revert such a patch (okay, there's only been one instance
so far) it means falling back to the old way. So that code exists
one way or t'other.
> > I guess we'll just have to live with the screwed history until some
> > of the issues I've brought up with git are resolved (the biggest one
> > being git commit being able to take a list of files deleted.)
>
> If you _are_ updating index yourself before calling git-commit,
> you do not need to (and indeed you should not) pass _any_
> pathnames to it. I think that's where this confusion comes from.
Yes, that is where the confusion's happening.
Thanks for explaining it - the script's now fixed and appears to work
as desired.
akpm - I'm afraid the ARM devel tree has been regenerated almost from
scratch, so you might encouter some issues next time you pull it.
However, despite this issue, the end result appears to be idential
(git-diff-tree -u broken-devel devel shows no changes, but the
individual changes for each commit are now correct.)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
next prev parent reply other threads:[~2006-09-24 21:34 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-24 11:02 2.6.18-mm1 Andrew Morton
2006-09-24 12:46 ` 2.6.18-mm1 Russell King
2006-09-24 13:11 ` 2.6.18-mm1 Russell King
2006-09-24 13:22 ` 2.6.18-mm1 Petr Baudis
2006-09-24 14:20 ` 2.6.18-mm1 Russell King
2006-09-24 14:29 ` 2.6.18-mm1 Petr Baudis
2006-09-24 14:47 ` 2.6.18-mm1 Russell King
2006-09-24 16:55 ` 2.6.18-mm1 Petr Baudis
2006-09-24 18:48 ` 2.6.18-mm1 Junio C Hamano
2006-09-24 21:34 ` Russell King [this message]
2006-09-24 21:56 ` 2.6.18-mm1 Andrew Morton
2006-09-24 22:07 ` 2.6.18-mm1 Junio C Hamano
2006-09-24 16:35 ` 2.6.18-mm1 Dmitry Torokhov
2006-09-24 17:06 ` 2.6.18-mm1 Andrew Morton
2006-09-27 2:04 ` 2.6.18-mm1 Eric W. Biederman
2006-09-27 3:11 ` 2.6.18-mm1 Andrew Morton
2006-09-27 5:12 ` 2.6.18-mm1 Eric W. Biederman
2006-09-27 5:44 ` 2.6.18-mm1 Aaron Durbin
2006-09-27 6:20 ` 2.6.18-mm1 Eric W. Biederman
2006-09-27 7:13 ` 2.6.18-mm1 Andi Kleen
2006-09-27 7:39 ` 2.6.18-mm1 Eric W. Biederman
2006-09-27 7:51 ` 2.6.18-mm1 Andi Kleen
2006-09-27 14:08 ` 2.6.18-mm1 Eric W. Biederman
2006-09-27 22:06 ` 2.6.18-mm1 Aaron Durbin
2006-09-27 23:06 ` 2.6.18-mm1 Andrew Morton
2006-09-27 9:25 ` 2.6.18-mm1 Andy Whitcroft
2006-09-27 16:12 ` 2.6.18-mm1 Andrew Morton
2006-09-27 16:50 ` 2.6.18-mm1 Andy Whitcroft
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060924213422.GD12795@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=akpm@osdl.org \
--cc=junkio@cox.net \
--cc=linux-kernel@vger.kernel.org \
--cc=pasky@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox