On 12/15/2015 05:49 PM, Moritz Barsnick wrote:
Hi Mats,
On Tue, Dec 15, 2015 at 16:58:41 +0100, Mats Peterson wrote:
Sorry if this may sound idiotic, but if I provide a unified patch for a
file that is newer/different from the one I have here, it won't work, right?
"It depends." ;-)
By the way, git handles this kind of stuff nicely.
It may or may not work. Obviously, if the file hasn't changed upstream,
your patch will still apply.
a) Best case: The files haven't changed upstream, your diff still
applies.
b) Good case: Upstream changed only unrelated parts of those file, your
diff applies, perhaps with an offset (i.e. shifted in line numbers).
b2) Almost as good: The unrelated changes are close to your changes, so
you get a so-called fuzz.
c) Bad case: Related parts were changed. Your diff won't apply, you
have to reintegrate your changes, perhaps even differently.
d) Worse case: Your patch applies, but affected methods were
incompatibly changed. This leads to build or runtime errors, or
broken functionality.
It's always a good idea to check upstream changes to see whether they
affect your patch. Most likely, a) or b) applies, but you don't know
until you've checked. :-)
Moritz
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Thanks for the enlightening answer, Moritz. Now I don't possess an
enormous amount of Git experience, but I guess it's best to get the
latest version from Git before providing any new patches. It makes life
easier for the potential testers, of course.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
