how to find outstanding patches in non-linux-2.6 repositories?

How do I get a list of commits in the 'powerpc' tree, which are not part of the 'linux-2.6' tree? The git tutorial has a section 'Working with Others', but the examples dont work for me. Probably because rsync://rsync.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git has no info that it is not the "mainline tree". All I need is a list of individual commits in that tree, which are not (yet) in "mainline". I could get them also from the ozlabs mailing lists, for the few patches I need. But it would be better if there is some sort of automated way to extract a list of differences between two trees.

Olaf Hering wrote:

Pull the powerpc tree into your local repo, then do something like: git-whatchanged master..powerpc or gitk master..powerpc

--
				Brian Gerst

 On Sun, Jan 01, Brian Gerst wrote:

This worked for me:

mkdir /dev/shm/x cd /dev/shm/x rsync -Ha --delete ~/kernel/git/{powerpc,linux-2.6} . cd linux-2.6/ cat .git/HEAD > ../start git-pull /dev/shm/x/powerpc cat .git/HEAD > ../end git-format-patch `cat ../start` `cat ../end` view ????-*

Hi,

On Sun, 1 Jan 2006, Olaf Hering wrote:

Preferrable is the following:

cd /existing/clone/of/ppc-linux # OP said he had this already
git fetch \
  git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git \
  master:refs/heads/linus
git-whatchanged linus..HEAD

Hth, Dscho

On Sun, 2006-01-01 at 15:32, Johannes Schindelin wrote:

Could someone remind me where the <ref>..<ref> syntax is documented, please? I went digging, but I am lame and couldn't find it.

Thanks, jdl

On Tuesday January 3rd 2006 Jon Loeliger wrote:

It is in the documentation for git-rev-list:

In the "Description" section for git-rev-list:

A special notation <commit1>..<commit2> can be used as a short-hand for ^<commit1> <commit2>.

Jon Loeliger wrote:

'man git-rev-parse' gets you the <committish> explanation. A ref is tag or a branch, and those are committish. A range such as <committish1>..<committish2> means "include all commits since and including <committish1>, leading up to (and including) <committish2>".

When Linus generates patches for the kernel he uses tags as <committish> and does something like this: git diff v2.6.14..v2.6.15 | gzip -9f > linux-2.6.14-2.6.15.patch.gz

You can mix tags, commits and branches any way you like, so long as you get the commitological order right. That is, <committish2> should refer to a descendant of <committish1>.

"origin..HEAD" is a valid and fairly common range. "HEAD..origin" is not (well, it is, but it doesn't include any commits since it's going backwards).

I don't know where to find a more complete explanation, but at least google should provide this one once it has gotten round to indexing this mail.

Now lets just have to hope I didn't get it all wrong. :)

On Tue, Jan 03, 2006 at 08:35:14PM +0100, Andreas Ericsson wrote:

It depends on what you are doing. When I update my git repository, I do

git fetch git-whatchanged master..origin git pull

to find out what changed since I last updated.

On Tue, 3 Jan 2006, Jon Loeliger wrote:

Hmm. It probably isn't. Technically, "start..end" is exactly the same thing as "end" + "^start", with an empty "end" being the same as HEAD (an empty "start" is largely meaningless and isn't supported - we _could_ make it mean the same as just specifying "end").

You can see this with "git-rev-parse":

	[torvalds@g5 linux]$ git-rev-parse v2.6.12..v2.6.15
	88026842b0a760145aa71d69e74fbc9ec118ca44
	^26791a8bcf0e6d33f43aef7682bdb555236d56de

ie it really does literally that transformation.

NOTE! Normally the "a" + "^b" format just means "everything that is reachable through "a", but not reachable through "b". In other words, it almost always ends up being a "commit set operation", and you can combine it with other "set" operations (like "--before=<date>" or other limiters).

But there is one special case: "git diff" will consider that to be a range of end-points, and will generate a diff from "b" to "a". It will do this regardless of whether "a" and "b" are even related, and it will _not_ care about set differences.

So there's a very fundamental difference between two things that _syntactically_ look very similar:

	git log a..b

and 

	git diff a..b

may look like they are related, but they really really are not. They are very very different.

The "git log" thing will show the commit log for every commit that is in "b" but not in "a". HOWEVER, if there's something in "a" that is not in "b" it will totally ignore it - it _literally_ means "show everything that is reachable from "b" but not reachable from "a".

So doing "git log a..b" and "git log b..a" are _not_ "reverse" operations. They show totally disjunct sets. If one is a superset of the other, one of those will be empty. But if they have different development, the two "git log" commands will show what happened on one side but not the other.

In contrast, "git diff a..b" will show the raw differences between two heads. So doing "git diff a..b" and "git diff b..a" is exactly the same thing, the diff will just be "reversed". It's not an operation on a set of commits: it's purely an operation on the two end-points.

So keep this in mind: the meaning of "a..b" actually depends on the operation you do, although in all cases it will be exactly equivalent to "a" and "^b" (with the special case for an empty "a" meaning HEAD).

			Linus

On Sun, 1 Jan 2006, Olaf Hering wrote:

First, get a kernel tree, let's say that you just get the standard one and thus my head will be in "origin" (and perhaps HEAD too, unless you decide to do some stuff of your own). Then just do something like

   git fetch \
	git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git \
	master:powerpc

which gets the master branch from the powerpc.git tree into your "powerpc" branch (or set up a .git/remotes/powerpc thing if you expect to do more of this).

Then you can just do

	gitk origin..powerpc

(or "git log" or "git-whatchanged -p" instead of "gitk") to see the commits that are in powerpc but not in "origin".

		Linus