linuxgitpatchgit-apply

check if git apply was already applied


This question is about git apply

Is there a way to distinguish between: it failed because...

  1. ... the patch is already applied
  2. ... the source code is really different

The directory i work in is not a git directory, therefore i can't use git log or something else.

I know about the -R (reverse) option, therefore my current workaround is this:

git apply abc.patch || git apply abc.patch -R --check && echo already applied

This way git apply abc.patch -R --check && git apply abc.patch will only be executed if git apply abc.patch fails, it then checks if it failed because the patch is already applied (git apply abc.patch -R --check) and if this is the case, it echoes "already applied"

But i don't like it, isn't there someting like a builtin-solution in git's apply?


Solution

  • The short answer is no, or at least, not generally.

    Consider: a patch is a set of directions saying "remove this line" and "add these other lines". Suppose the patch for file reads, in its entirety:

    diff --git a/file b/file
    index 87cdbbd..3d8696b 100644
    --- a/file
    +++ b/file
    @@ -7,4 +7,3 @@ this file is dull
     this file is dull
     this file is dull
     this file is dull
    -this file is dull
    

    In other words, the input file was very dull, at least towards the end, where it just kept repeating "this file is dull".

    The change to the file was to delete one of those dull lines. The context is more, equally dull lines, followed by "end of file".

    Since the patch was generated, someone modified the top of the file so that it's no longer just 10 (or 9) dull lines, but it still ends with at least four dull lines. The file is now over 50 lines long with most of the top ones pretty exciting, comparatively at least.

    Can you, as a smart human, tell whether or not the patch to this file has been applied yet? All I will tell you is that the patch may or may not have been applied, along with the other changes that added many exciting lines at the top of the file.

    If you can't tell, why would you believe Git can? I don't know about you, but I can't tell if the change that added the exciting lines also deleted the final dull one.

    (Now, in some cases—especially if you have that index 87cdbbd..3d8696b 100644 line—there is a way to tell, provided that you also have a committed version of the file whose hash ID is 87cdbbd, because now we can extract that particular version of the file. But you haven't said whether you have the index line, and if so, whether you also have a blob with a matching hash ID.)