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