We write them under another name and rename them to their destination,
so that if something bad happens in the middle, we won't have caused any
bigger harm.

Also, this makes the writing be NFS "intr" safe, and as a side effects
makes sure that if the target is hardlinked (or symlinked) we will have
broken the link.

apply.c: In function `show_rename_copy':
apply.c:1147: warning: field precision is not type int (arg 3)
Signed-off-by: NTony Luck <tony.luck@intel.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

IIRC our strategy was to let the users' umask take care of the
final mode bits.  This patch fixes places that deviate from it.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Mainly making a lot of local functions and variables be marked "static",
but there was a "zero as NULL" warning in there too.

Also, remove debugging statement about applying a fragment at an offset.

Typical expected usage is "git-apply --stat --summary" to show
diffstat plus dense description of information available in git
extended headers, such as creations, renames, and mode changes.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

When a patch is a git extended rename/copy patch, "git-apply
--stat" showed the old filename.  Change it to show the new
filename, because most of the time we are interested in looking
at the resulting tree.
Signed-off-by: NJunio C Hamano <junkio@cox.net>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Applying Andrew's latest patch-bomb showed us failing miserably if a new
subdirectory needed to be created..  That said, it's uncommon enough
that it's worth optimistically assuming it won't be needed, and then
creating the subdirectories only on failure.

Diffs with only mode changes didn't pass through git-apply --stat.

[ Linus' note: they did for me, on my ppc64, where division by zero just
  silently returns zero.  Duh.  ]
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

Pure mode changes won't have the file-name in the extended header lines,
so make sure we pick it up from the default name from the "diff --git"
line.

Sine git only saves the 'x' bit, we shouldn't compare the stat contents
directly.

Missing argument for error() function. We should really use the
gcc printf format checking capabilities.

A meaningful (ie non-empty) git patch always has more information in the
header than just the "diff --git" line itself: it needs to have either a
patch associated with it (which implies "---" and "+++" lines in the
header) or it needs to have rename/copy/delete/create information in it.

Just ignore git patches which have no change information. Otherwise we'll
end up with a patch that doesn't have filenames etc filled in, and we'll
be unhappy.

(but it will result in a warning)

Clearly even Junio felt git "rename" header lines should say "from/to"
instead of "old/new", since he wrote the documentation that way.

This way it also matches "copy".

git-apply will accept both versions, at least for a while.

A "--stat" or a "--check" will just be quiet, but if
you try to apply something with no changes, that's an
error.

It's not "rename from" and "rename to", it's "rename old" and "rename new".

Which is illogical and doesn't match the "copy from/to" case, but that's
life. Maybe Junio will fix it up one of these days.

We update the index only if the "--index" flag is given,
so you can actually use this as a strange kind of "patch"
program even for non-git usage. Not that you'd likely
want to, but it comes in handy for testing.

This _should_ more or less get everythign right, but as
usual I leave the testing to the usrs..

(And fix name handling for when we have an implied
create or delete event from a traditional diff).

This applies the fragments in memory, but doesn't actually
write the results out to the files yet. But we now do all the
difficult parts, the rest is just basically writing the
results out and updating the index.

Right now it requires that the fragment offsets be exact,
and it doesn't actually apply the fragment yet, but it
does find where it goes and verify the data.

Next step: actually applying the fragment changes.

It had already tried to do that, but with the independent
rounding of the number of '+' and '-' characters, it would
sometimes do 80-char lines after all.

It just causes things like "git-apply --stat" to parse traditional
patch headers differently depending on what your index is, which
is nasty.

The way broken deletes and creates are shown in the -p
(diff-patch) output format has become consistent with how
rename/copy edits are shown.  They will show "dissimilarity
index" value, immediately following the "deleted file mode" and
"new file mode" lines.

The git-apply is taught to grok such an extended header.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

It currently only verifies the index against the working directory,
it doesn't actually verify the diff fragments themselves yet.

This means that filenames are totally unambiguous even if they
have spaces or tabs in them.

Pure mode changes, and deletes or creates of empty files won't have this
information anywhere else.

Slowly this is takign the form of a program that we'd actually
use. Now "git-apply --stat" basically ends up being a perfectly
useful diffstat.

Hey, it's almost free by now, and it's a good way to see that
we parse the patches correctly.

Make it a clear two-phase thing: first a read-only parse of
the patch itself (which is independent of any current index
information), and then the second phase actually uses the patch.

The second phase might not be a real apply, it could be just a
diffstat, for example. Which is trivial to do once the patch is
parsed.

Not important but I am a bit annoyed by gcc complaining about the
control falling out of the function without returning value.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>

There's some duplication of filenames when doing filename operations
(creates, deletes, renames and copies), and this makes us verify that
the pathnames match when they should.

Right now we only use it to figure out what the filename might
be when that is ambiguous, but we'll get there..

This makes it act more like a traditional UNIX thing (eg "cat").

.. and print out the information. This sets up all the pathname
information, and whether it's a new file, deleted file, rename,
copy or whatever.

It's slowly getting to the point where it all comes together,
and we can actually apply all the information that we've gathered.

In particular, give line numbers when detecting corrupt patches.
This makes the tool a lot more friendly (indeed, much more so
than regular "patch", I think).

Don't just stop at them and look for the next header. Die,
die, die!

This applies git patches (and old-style unified diffs)
in the index, rather than doing it in the working directory.

That allows for a lot more flexibility, and means that if a
patch fails, we aren't going to mess up the working directory.

NOTE! This is just the first cut at it, and right now it only
parses the incoming patch, it doesn't actually apply it yet.