# Figuring out which patches have been applied

3 messages from 2009-10-02 to 2009-10-02. Participants: Jon Smirl, Julian Phillips, skillzero@gmail.com.
Thread: https://gitlist.dev/t/21113

## Jon Smirl, 2009-10-02 14:36

Subject: Figuring out which patches have been applied
Message-ID: <9e4733910910020736n539f4331nfd61175b275c7d28@mail.gmail.com>
URL: https://gitlist.dev/e/9e4733910910020736n539f4331nfd61175b275c7d28%40mail.gmail.com

```
I have a stack of 100 patches against 2.6.30. A lot of these got
merged between 2.6.30-32.  How can I tell which ones have been
applied?

It doesn't work to check if patch A has been applied to 2.6.32. Other
patches may have been applied on top of patch A obscuring it.

Once solution would be to rebase the patch stack forward one commit at
a time. That solves the problem of later patches obscuring patch A. Is
there a better way to do this?

-- 
Jon Smirl
jonsmirl@gmail.com

```

## Julian Phillips, 2009-10-02 18:45

Subject: Re: Figuring out which patches have been applied
Message-ID: <alpine.LNX.2.00.0910021944040.28646@reaper.quantumfyre.co.uk>
URL: https://gitlist.dev/e/alpine.LNX.2.00.0910021944040.28646%40reaper.quantumfyre.co.uk
In-Reply-To: <9e4733910910020736n539f4331nfd61175b275c7d28@mail.gmail.com>

```
On Fri, 2 Oct 2009, Jon Smirl wrote:

> I have a stack of 100 patches against 2.6.30. A lot of these got
> merged between 2.6.30-32.  How can I tell which ones have been
> applied?
>
> It doesn't work to check if patch A has been applied to 2.6.32. Other
> patches may have been applied on top of patch A obscuring it.
>
> Once solution would be to rebase the patch stack forward one commit at
> a time. That solves the problem of later patches obscuring patch A. Is
> there a better way to do this?

Have you tried using git-cherry?  I belive that it was intended for this 
purpose?

-- 
Julian

  ---
Progress might have been all right once, but it's gone on too long.
 		-- Ogden Nash

```

## skillzero@gmail.com, 2009-10-02 19:16

Subject: Re: Figuring out which patches have been applied
Message-ID: <2729632a0910021216v7b3c5dadi14a6f8c0ea41b6b9@mail.gmail.com>
URL: https://gitlist.dev/e/2729632a0910021216v7b3c5dadi14a6f8c0ea41b6b9%40mail.gmail.com
In-Reply-To: <9e4733910910020736n539f4331nfd61175b275c7d28@mail.gmail.com>

```
On Fri, Oct 2, 2009 at 7:36 AM, Jon Smirl <jonsmirl@gmail.com> wrote:
> I have a stack of 100 patches against 2.6.30. A lot of these got
> merged between 2.6.30-32.  How can I tell which ones have been
> applied?
>
> It doesn't work to check if patch A has been applied to 2.6.32. Other
> patches may have been applied on top of patch A obscuring it.
>
> Once solution would be to rebase the patch stack forward one commit at
> a time. That solves the problem of later patches obscuring patch A. Is
> there a better way to do this?

There may be a better way, but I needed to do a similar thing with
commits that were cherry-pick'd so I wrote a simple
git-contains-equivalent script to search for equivalent patch ID's
given a commit ID. You could do something like that, but using
git-patch-id as the source instead getting it from an existing commit
like the following script does.

#!/bin/bash

set -o pipefail
searchCommitID=`git rev-parse $1`
searchPatchID=`git show $searchCommitID | git patch-id`
if [ $? -ne 0 ]; then
	exit 1
fi
searchPatchID=${searchPatchID% *}

echo "Searching for equivalents to commit $searchCommitID (patch
$searchPatchID)..."
git log --all -p | git patch-id | grep $searchPatchID |
while read patchID commitID; do
	if [ "$commitID" = "$searchCommitID" ]; then
		echo "Exact commit $commitID is on the following branches:"
	else
		echo "Equivalent commit $commitID is on the following branches:"
	fi
	git branch -a --contains $commitID
done

```