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

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

[Olaf Hering]

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.

-- 
short story of a lazy sysadmin:
 alias appserv=wotan

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

[Brian Gerst]

Olaf Hering wrote:
> 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.
> 

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

--
				Brian Gerst

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

[Olaf Hering]

 On Sun, Jan 01, Brian Gerst wrote:

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

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 ????-*



-- 
short story of a lazy sysadmin:
 alias appserv=wotan

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

[Johannes Schindelin]

Hi,

On Sun, 1 Jan 2006, Olaf Hering wrote:

>  On Sun, Jan 01, Brian Gerst wrote:
> 
> > Pull the powerpc tree into your local repo, then do something like:
> > git-whatchanged master..powerpc
> > or
> > gitk master..powerpc
> 
> 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 ????-*

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

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

[Linus Torvalds]

On Sun, 1 Jan 2006, Olaf Hering wrote:
> 
> 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".

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

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

[Jon Loeliger]

On Sun, 2006-01-01 at 15:32, Johannes Schindelin 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

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

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

[Marco Roeland]

On Tuesday January 3rd 2006 Jon Loeliger 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.

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>.
-- 
Marco Roeland

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

[Andreas Ericsson]

Jon Loeliger 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.
> 

'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. :)

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

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

[Linus Torvalds]

On Tue, 3 Jan 2006, Jon Loeliger 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.

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

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

[Tom Prince]

On Tue, Jan 03, 2006 at 08:35:14PM +0100, Andreas Ericsson wrote:
> "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).
> 

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.