On Mon, 18 Apr 2005, Russell King wrote:
> Ok, since the last one was soo successful, and I'm up for more
> punishment, here's another attempt.  The diffstat is rather
> interesting in this one, claiming no changes.  It should look
> like this:
>  arch/arm/lib/bitops.h |   33 +++++++++++++++++++++++++++++++++
>  1 files changed, 33 insertions(+)
> However, it seems that git diff can't handle new files appearing
> yet.

It should definitely be able to do that. 

Do a "git log | less" to look up the trees involved, and do a "git diff
<parent-tree> <child-tree>" to see the output. If you don't see your new
file, then either you have an old "git diff" that doesn't like the new
tools (and you need to add a "-z"  flag to diff-tree), or you didn't 
check in the new file successfully ;)

You can also always do "tree-diff -r old-tree new-tree" which will show
you the tree-level changes. That's the low-level plumbing stuff: it 
doesn't show you the actual file contents, just how the tree changed.

> The other interesting thing to note is that patches are generated
> for '-p0' rather than '-p1' application, which is contary to our
> historical requirements.  This is going to confuse people - can
> we make it generate -p1 patches please?

That should already be the case now after the latest diffs from Junio.

> Linus - assuming I un-messed-up my tree properly (it appears to
> be correct and fsck-cache $(commit-id) is happy) please merge
> this. 

Looks ok, which seems to mean that your scripts are buggered since they 
didn't pick up the new file.

Merge pushed out.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to