[howto] Kernel hacker's guide to git, updated

[howto] Kernel hacker's guide to git, updated

[Jeff Garzik]

Just updated my KHGtG to include the latest goodies available in 
git-core, the Linux kernel standard SCM tool:

	http://linux.yyz.us/git-howto.html

Several changes in git-core have made working with git a lot easier, so 
be sure to re-familiarize yourself with the development process.

Comments, corrections, and notes of omission welcome.  This document 
mainly reflects my typical day-to-day git activities, and may not be 
very applicable outside of kernel work.

	Jeff

Re: [howto] Kernel hacker's guide to git, updated

[David Leimbach]

On 9/29/05, Jeff Garzik <jgarzik@pobox.com> wrote:
>
> Just updated my KHGtG to include the latest goodies available in
> git-core, the Linux kernel standard SCM tool:
>
>         http://linux.yyz.us/git-howto.html

Can you update the date on that page to reflect your latest updates? 
I was digging around with git yesterday and had a few surprises...
like checking out the kernel and being told I modified a bunch of
files I never touched.

- Dave

Re: [howto] Kernel hacker's guide to git, updated

[Alberto Patino]

On 9/29/05, David Leimbach <leimy2k@gmail.com> wrote:
> On 9/29/05, Jeff Garzik <jgarzik@pobox.com> wrote:
> >
> > Just updated my KHGtG to include the latest goodies available in
> > git-core, the Linux kernel standard SCM tool:
> >
> >         http://linux.yyz.us/git-howto.html
>
> Can you update the date on that page to reflect your latest updates?
> - Dave

The  KHGtG page is updated to September 29, 2005.



--
Don't be evil!!!

Re: [howto] Kernel hacker's guide to git, updated

[David Leimbach]

On 9/29/05, Alberto Patino <pato.lukaz@gmail.com> wrote:
> On 9/29/05, David Leimbach <leimy2k@gmail.com> wrote:
> > On 9/29/05, Jeff Garzik <jgarzik@pobox.com> wrote:
> > >
> > > Just updated my KHGtG to include the latest goodies available in
> > > git-core, the Linux kernel standard SCM tool:
> > >
> > >         http://linux.yyz.us/git-howto.html
> >
> > Can you update the date on that page to reflect your latest updates?
> > - Dave
>
> The  KHGtG page is updated to September 29, 2005.
>
>
Awesome!  Thanks. :-)  I'm looking at cogito and darcs-git for working
with v9fs and other goodies.

Dave

Re: [howto] Kernel hacker's guide to git, updated

[Oliver Neukum]

Am Donnerstag, 29. September 2005 13:03 schrieb Jeff Garzik:
> 
> Just updated my KHGtG to include the latest goodies available in 
> git-core, the Linux kernel standard SCM tool:
> 
> 	http://linux.yyz.us/git-howto.html
> 
> Several changes in git-core have made working with git a lot easier, so 
> be sure to re-familiarize yourself with the development process.
> 
> Comments, corrections, and notes of omission welcome.  This document 
> mainly reflects my typical day-to-day git activities, and may not be 
> very applicable outside of kernel work.

Unfortunately, following the instructions to the letter produces this:
oliver@oenone:~/linux-2.6> git checkout
usage: read-tree (<sha> | -m <sha1> [<sha2> <sha3>])

	Regards
		Oliver

Re: [howto] Kernel hacker's guide to git, updated

[Jon Loeliger]

On Thu, 2005-09-29 at 14:08, Oliver Neukum wrote:

> Unfortunately, following the instructions to the letter produces this:
> oliver@oenone:~/linux-2.6> git checkout
> usage: read-tree (<sha> | -m <sha1> [<sha2> <sha3>])

Yeah.  See if you still have a .git/HEADS that symlinks
to a valid place or not...?

jdl

Re: [howto] Kernel hacker's guide to git, updated

[Oliver Neukum]

Am Donnerstag, 29. September 2005 21:34 schrieb Jon Loeliger:
> On Thu, 2005-09-29 at 14:08, Oliver Neukum wrote:
> 
> > Unfortunately, following the instructions to the letter produces this:
> > oliver@oenone:~/linux-2.6> git checkout
> > usage: read-tree (<sha> | -m <sha1> [<sha2> <sha3>])
> 
> Yeah.  See if you still have a .git/HEADS that symlinks
> to a valid place or not...?

oliver@oenone:~/linux-2.6> ls -la .git/
insgesamt 14
drwxrwxr-x    6 oliver users  224 2005-09-29 21:06 .
drwxr-xr-x    3 oliver users   72 2005-09-29 20:45 ..
-rw-rw-r--    1 oliver users   19 2005-05-02 01:02 description
lrwxrwxrwx    1 oliver users   17 2005-09-29 21:06 HEAD -> refs/heads/master
-rw-------    1 oliver users   32 2005-09-29 21:06 index
drwxrwxr-x    2 oliver users  104 2005-09-11 21:41 info
drwxr-xr-x  260 oliver users 6240 2005-09-29 19:05 objects
drwxrwxr-x    4 oliver users   96 2005-05-02 02:15 refs
drwxr-xr-x    2 oliver users   72 2005-09-29 21:05 remotes
oliver@oenone:~/linux-2.6> ls -la .git/refs/
insgesamt 1
drwxrwxr-x  4 oliver users  96 2005-05-02 02:15 .
drwxrwxr-x  6 oliver users 224 2005-09-29 21:06 ..
drwxrwxr-x  2 oliver users  72 2005-09-29 19:05 heads
drwxrwxr-x  2 oliver users 600 2005-09-20 05:02 tags
oliver@oenone:~/linux-2.6> ls -la .git/refs/heads/
insgesamt 4
drwxrwxr-x  2 oliver users 72 2005-09-29 19:05 .
drwxrwxr-x  4 oliver users 96 2005-05-02 02:15 ..
-rw-rw-r--  1 oliver users 41 2005-09-29 19:05 master
oliver@oenone:~/linux-2.6> cat .git/refs/heads/master
aa55a08687059aa169d10a313c41f238c2070488

	Regards
		Oliver

Re: [howto] Kernel hacker's guide to git, updated

[Dave Jones]

On Thu, Sep 29, 2005 at 07:03:05AM -0400, Jeff Garzik wrote:
 > 
 > Just updated my KHGtG to include the latest goodies available in 
 > git-core, the Linux kernel standard SCM tool:
 > 
 > 	http://linux.yyz.us/git-howto.html
 > 
 > Several changes in git-core have made working with git a lot easier, so 
 > be sure to re-familiarize yourself with the development process.
 > 
 > Comments, corrections, and notes of omission welcome.  This document 
 > mainly reflects my typical day-to-day git activities, and may not be 
 > very applicable outside of kernel work.

You wrote..

$ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
$ cd linux-2.6
$ rsync -a --verbose --stats --progress \
  rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
  .git/

Could be just..

$ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
$ cd linux-2.6
$ git pull

Likewise, in the next section, git pull doesn't need an argument
if pulling from the repo it cloned.

		Dave

Re: [howto] Kernel hacker's guide to git, updated

[Anton Altaparmakov]

On Thu, 29 Sep 2005, Dave Jones wrote:
> On Thu, Sep 29, 2005 at 07:03:05AM -0400, Jeff Garzik wrote:
>  > Just updated my KHGtG to include the latest goodies available in 
>  > git-core, the Linux kernel standard SCM tool:
>  > 
>  > 	http://linux.yyz.us/git-howto.html
>  > 
>  > Several changes in git-core have made working with git a lot easier, so 
>  > be sure to re-familiarize yourself with the development process.
>  > 
>  > Comments, corrections, and notes of omission welcome.  This document 
>  > mainly reflects my typical day-to-day git activities, and may not be 
>  > very applicable outside of kernel work.
> 
> You wrote..
> 
> $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
> $ cd linux-2.6
> $ rsync -a --verbose --stats --progress \
>   rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
>   .git/
> 
> Could be just..
> 
> $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
> $ cd linux-2.6
> $ git pull

That is not actually the same.  "git pull" for example will not download 
Linus' tags whilst the rsync would get everything.

> Likewise, in the next section, git pull doesn't need an argument
> if pulling from the repo it cloned.

Now that is definitely correct.  (-:

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: [howto] Kernel hacker's guide to git, updated

[Dave Jones]

On Thu, Sep 29, 2005 at 09:07:29PM +0100, Anton Altaparmakov wrote:

 > > $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
 > > $ cd linux-2.6
 > > $ rsync -a --verbose --stats --progress \
 > >   rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
 > >   .git/
 > > 
 > > Could be just..
 > > 
 > > $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
 > > $ cd linux-2.6
 > > $ git pull
 > 
 > That is not actually the same.  "git pull" for example will not download 
 > Linus' tags whilst the rsync would get everything.

Ah. I didn't know this. Thanks.
Hmm, it'd be nice to have a shorthand 'not have to type the url, pull everything'.
Something like 'git pull all'.

		Dave

Re: [howto] Kernel hacker's guide to git, updated

[Jeff Garzik]

Dave Jones wrote:
> You wrote..
> 
> $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
> $ cd linux-2.6
> $ rsync -a --verbose --stats --progress \
>   rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
>   .git/
> 
> Could be just..
> 
> $ git clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-2.6
> $ cd linux-2.6
> $ git pull
> 
> Likewise, in the next section, git pull doesn't need an argument
> if pulling from the repo it cloned.


Nope.  It intentionally includes the manual rsync because clone/pull 
doesn't seem to grab tags.  Or at least last time I checked...

	Jeff

Re: [howto] Kernel hacker's guide to git, updated

[Junio C Hamano]

Jeff Garzik <jgarzik@pobox.com> writes:

> Nope.  It intentionally includes the manual rsync because clone/pull 
> doesn't seem to grab tags.  Or at least last time I checked...

clone does (or should), fetch (and hence pull) does not
automatically.  Running the following one-liner every once in a
while would sync your set of tags with Linus:

git fetch origin `git-ls-remote --tags origin | sed -ne 's|^.*refs/tags/|tag |p'`

Re: [howto] Kernel hacker's guide to git, updated

[Linus Torvalds]

On Thu, 29 Sep 2005, Dave Jones wrote:
>
> Ah. I didn't know this. Thanks.
> Hmm, it'd be nice to have a shorthand 'not have to type the url, pull everything'.
> Something like 'git pull all'.

Something like this?

Except it's called "git fetch --all", and it's obviously totally untested.

 		Linus
--
diff --git a/git-fetch.sh b/git-fetch.sh
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -5,6 +5,8 @@
  _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
  _x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"

+all=
+tags=
  append=
  force=
  update_head_ok=
@@ -17,6 +19,12 @@ do
  	-f|--f|--fo|--for|--forc|--force)
  		force=t
  		;;
+	--tags)
+		tags=t
+		;;
+	--all)
+		all=t
+		;;
  	-u|--u|--up|--upd|--upda|--updat|--update|--update-|--update-h|\
  	--update-he|--update-hea|--update-head|--update-head-|\
  	--update-head-o|--update-head-ok)
@@ -158,7 +166,16 @@ case "$update_head_ok" in
  	;;
  esac

-for ref in $(get_remote_refs_for_fetch "$@")
+taglist=
+if [ "$tags$all" ]; then
+	pattern='/refs\/tags/'
+	if [ "$all" ]; then
+		pattern='/refs/'
+	fi
+	taglist=$(git-ls-remote "$remote" | awk "$pattern"' { print $2":"$2 }')
+fi
+
+for ref in $(get_remote_refs_for_fetch "$@" $taglist)
  do
      refs="$refs $ref"

Re: [howto] Kernel hacker's guide to git, updated

[Chuck Lever]

[-- Attachment #1: Type: text/plain, Size: 1168 bytes --]

Jeff Garzik wrote:
> Dave Jones wrote:
> 
>> You wrote..
>>
>> $ git clone 
>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git 
>> linux-2.6
>> $ cd linux-2.6
>> $ rsync -a --verbose --stats --progress \
>>   
>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ 
>> \
>>   .git/
>>
>> Could be just..
>>
>> $ git clone 
>> rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git 
>> linux-2.6
>> $ cd linux-2.6
>> $ git pull
>>
>> Likewise, in the next section, git pull doesn't need an argument
>> if pulling from the repo it cloned.
> 
> 
> 
> Nope.  It intentionally includes the manual rsync because clone/pull 
> doesn't seem to grab tags.  Or at least last time I checked...

i just used the instructions at the bottom of your web page to grab new 
tags, and it completely wiped all my Stacked Git metadata.  (fortunately 
i was trying this in a test repository, and it will be simple to recover 
the missing files).

so, this is probably something that should have a warning, or maybe you 
might consider providing an example that won't wipe out existing files 
and directories under .git/ ...

[-- Attachment #2: cel.vcf --]
[-- Type: text/x-vcard, Size: 439 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Charles
org:Network Appliance, Incorporated;Linux NFS Client Development
adr:535 West William Street, Suite 3100;;Center for Information Technology Integration;Ann Arbor;MI;48103-4943;USA
email;internet:cel@citi.umich.edu
title:Member of Technical Staff
tel;work:+1 734 763 4415
tel;fax:+1 734 763 4434
tel;home:+1 734 668 1089
x-mozilla-html:FALSE
url:http://www.monkey.org/~cel/
version:2.1
end:vcard

Re: [howto] Kernel hacker's guide to git, updated

[Linus Torvalds]

On Thu, 29 Sep 2005, Linus Torvalds wrote:
>
> Something like this?

Gaah. Using a new pine version, and it is back to corrupting whitespace.

Damn all mailer writers. Do they think email is just for grandma?

 		Linus

Re: [howto] Kernel hacker's guide to git, updated

[Dave Jones]

On Thu, Sep 29, 2005 at 02:26:42PM -0700, Linus Torvalds wrote:

 > On Thu, 29 Sep 2005, Linus Torvalds wrote:
 > >
 > >Something like this?
 > 
 > Gaah. Using a new pine version, and it is back to corrupting whitespace.
 > 
 > Damn all mailer writers. Do they think email is just for grandma?

What I find amusing is that it was a patch rejection mail from you
*years* back (circa 2000 iirc), telling me my pine corrupted whitespace,
that made me switch MUA ;-)

All these years later, and it's still buggered ?

		Dave

Re: [howto] Kernel hacker's guide to git, updated

[Elfyn McBratney]

[-- Attachment #1: Type: text/plain, Size: 699 bytes --]

On Thu, Sep 29, 2005 at 02:26:42PM -0700, Linus Torvalds wrote:
 > 
 > 
 > On Thu, 29 Sep 2005, Linus Torvalds wrote:
 > >Something like this?
 > 
 > Gaah. Using a new pine version, and it is back to corrupting whitespace.
 > 
 > Damn all mailer writers. Do they think email is just for grandma?

Of course - grandma uses pine, hackers use mutt ;)

*hides*

Best,
Elfyn

-- 
Elfyn McBratney
Gentoo Developer/Perl Team Lead
beu/irc.freenode.net                            http://dev.gentoo.org/~beu/
+------------O.o--------------------- http://dev.gentoo.org/~beu/pubkey.asc

PGP Key ID: 0x69DF17AD
PGP Key Fingerprint:
  DBD3 B756 ED58 B1B4 47B9  B3BD 8D41 E597 69DF 17AD

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [howto] Kernel hacker's guide to git, updated

[Linus Torvalds]

On Thu, 29 Sep 2005, Linus Torvalds wrote:
> 
> Gaah. Using a new pine version, and it is back to corrupting whitespace.

Ok, disabling "text flowing" seems to have fixed it. It still leaves empty 
spaces at the end of lines when doing normal word-wrapping in the editor 
(and then seems to use those empty spaces as a "marker" for flowing), but 
that's at least just a small silly detail.

So how about this patch now? With it you can do

	git fetch --tags <linus-kernel-repo>

and it should fetch all my tags automatically.

		Linus
---
diff --git a/git-fetch.sh b/git-fetch.sh
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -5,6 +5,8 @@
 _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
 _x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
 
+all=
+tags=
 append=
 force=
 update_head_ok=
@@ -17,6 +19,12 @@ do
 	-f|--f|--fo|--for|--forc|--force)
 		force=t
 		;;
+	--tags)
+		tags=t
+		;;
+	--all)
+		all=t
+		;;
 	-u|--u|--up|--upd|--upda|--updat|--update|--update-|--update-h|\
 	--update-he|--update-hea|--update-head|--update-head-|\
 	--update-head-o|--update-head-ok)
@@ -158,7 +166,16 @@ case "$update_head_ok" in
 	;;
 esac
 
-for ref in $(get_remote_refs_for_fetch "$@")
+taglist=
+if [ "$tags$all" ]; then
+	pattern='/refs\/tags/'
+	if [ "$all" ]; then
+		pattern='/refs/'
+	fi
+	taglist=$(git-ls-remote "$remote" | awk "$pattern"' { print $2":"$2 }')
+fi
+
+for ref in $(get_remote_refs_for_fetch "$@" $taglist)
 do
     refs="$refs $ref"
 

Re: [howto] Kernel hacker's guide to git, updated

[Dave Jones]

On Thu, Sep 29, 2005 at 02:35:15PM -0700, Linus Torvalds wrote:
 > 
 > 
 > On Thu, 29 Sep 2005, Linus Torvalds wrote:
 > > 
 > > Gaah. Using a new pine version, and it is back to corrupting whitespace.
 > 
 > Ok, disabling "text flowing" seems to have fixed it. It still leaves empty 
 > spaces at the end of lines when doing normal word-wrapping in the editor 
 > (and then seems to use those empty spaces as a "marker" for flowing), but 
 > that's at least just a small silly detail.
 > 
 > So how about this patch now? With it you can do
 > 
 > 	git fetch --tags <linus-kernel-repo>
 > 
 > and it should fetch all my tags automatically.

Seems to work. I blew away git/refs/tags/v2.6.13*
and git fetch --tags fetched them all back just fine.

		Dave

Re: [howto] Kernel hacker's guide to git, updated

[Linus Torvalds]

On Thu, 29 Sep 2005, Dave Jones wrote:
>
> What I find amusing is that it was a patch rejection mail from you
> *years* back (circa 2000 iirc), telling me my pine corrupted whitespace,
> that made me switch MUA ;-)
> 
> All these years later, and it's still buggered ?

Actually, it seems better. It seems to be buggered by default, but it used 
to be that you had to actually recompile pine to make it behave. Now you 
can just disable "strip-whitespace-before-send" and _enable_ 
"quell-flowed-text" and those together seem to do the trick. No extra 
patches or recompiles necessary.

So there's progress. 

Of course, pico is still pico. Which I find a bit sad: my editor of choise 
is still an improved version of uemacs, and pico actually comes from the 
same uemacs history, but has different key-bindings for just enough keys 
to be slightly confusing.

Still, that shared history means that I find pico a lot more to my taste 
than just about any other emailer editor out there. It may have a few 
differences, but it has more things in common..

		Linus

Re: [howto] Kernel hacker's guide to git, updated

[Anton Altaparmakov]

On Thu, 29 Sep 2005, Linus Torvalds wrote:
> On Thu, 29 Sep 2005, Dave Jones wrote:
> > What I find amusing is that it was a patch rejection mail from you
> > *years* back (circa 2000 iirc), telling me my pine corrupted whitespace,
> > that made me switch MUA ;-)
> > 
> > All these years later, and it's still buggered ?
> 
> Actually, it seems better. It seems to be buggered by default, but it used 
> to be that you had to actually recompile pine to make it behave. Now you 
> can just disable "strip-whitespace-before-send" and _enable_ 
> "quell-flowed-text" and those together seem to do the trick. No extra 
> patches or recompiles necessary.

Indeed.  I use those two options like that, too.  (-:

> So there's progress. 
> 
> Of course, pico is still pico. Which I find a bit sad: my editor of choise 
> is still an improved version of uemacs, and pico actually comes from the 
> same uemacs history, but has different key-bindings for just enough keys 
> to be slightly confusing.
> 
> Still, that shared history means that I find pico a lot more to my taste 
> than just about any other emailer editor out there. It may have a few 
> differences, but it has more things in common..

Why don't you enable "enable-alternate-editor-implicitly" and set 
editor = "your-editor-of-choice" in the pine config?  It is integrated in 
a quite seamless way.

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: [howto] Kernel hacker's guide to git, updated

[Linus Torvalds]

On Thu, 29 Sep 2005, Anton Altaparmakov wrote:
> 
> Why don't you enable "enable-alternate-editor-implicitly" and set 
> editor = "your-editor-of-choice" in the pine config?  It is integrated in 
> a quite seamless way.

You think so? I don't find it that way.

With an alternate editor you have to edit the headers separately, and 
things like postponing a message suddenly turns into a big deal, not just 
a trivial ^O. In fact, almost everything gets more involved.

And pico _is_ pretty close to uemacs.

		Linus

Re: [howto] Kernel hacker's guide to git, updated

[Anton Altaparmakov]

On Thu, 29 Sep 2005, Linus Torvalds wrote:
> On Thu, 29 Sep 2005, Anton Altaparmakov wrote:
> > Why don't you enable "enable-alternate-editor-implicitly" and set 
> > editor = "your-editor-of-choice" in the pine config?  It is integrated in 
> > a quite seamless way.
> 
> You think so? I don't find it that way.
> 
> With an alternate editor you have to edit the headers separately, and 
> things like postponing a message suddenly turns into a big deal, not just 
> a trivial ^O. In fact, almost everything gets more involved.

Well using vim as alternate editor a postpone turns into a "ZZ" followed 
by ^O which I don't think is such a big deal but in general I agree that 
it adds hassle.  It is a shame that the text based headers do not appear 
as part of the message in the editor in particular...
 
> And pico _is_ pretty close to uemacs.

I wouldn't know about that.  Never used uemacs.  I am a vim addict myself.  
(-;

Best regards,

	Anton
-- 
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/

Re: [howto] Kernel hacker's guide to git, updated

[Horst von Brand]

Linus Torvalds <torvalds@osdl.org> wrote:

[...]

> Of course, pico is still pico. Which I find a bit sad: my editor of choise 
> is still an improved version of uemacs, and pico actually comes from the 
> same uemacs history, but has different key-bindings for just enough keys 
> to be slightly confusing.

Can I get a URL for the source for your editor? The one on kernel.org
doesn't compile, and probably hasn't for a long time.

[Yes, there is some (perverse) fun in telling people you use the very same
 editor than Linus Torvalds :-]> 
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [howto] Kernel hacker's guide to git, updated

[Junio C Hamano]

Anton Altaparmakov <aia21@cam.ac.uk> writes:

> On Thu, 29 Sep 2005, Linus Torvalds wrote:
>> On Thu, 29 Sep 2005, Dave Jones wrote:
>> > What I find amusing is that it was a patch rejection mail from you
>> > *years* back (circa 2000 iirc), telling me my pine corrupted whitespace,
>> > that made me switch MUA ;-)
>> > 
>> > All these years later, and it's still buggered ?
>> 
>> Actually, it seems better. It seems to be buggered by default, but it used 
>> to be that you had to actually recompile pine to make it behave. Now you 
>> can just disable "strip-whitespace-before-send" and _enable_ 
>> "quell-flowed-text" and those together seem to do the trick. No extra 
>> patches or recompiles necessary.
>
> Indeed.  I use those two options like that, too.  (-:

Anybody interested in adding entry to SubmittingPatches MUA
Specific Help section?

Re: [howto] Kernel hacker's guide to git, updated

[Linus Torvalds]

On Thu, 29 Sep 2005, Horst von Brand wrote:
> 
> Can I get a URL for the source for your editor? The one on kernel.org
> doesn't compile, and probably hasn't for a long time.

Oh, it compiles with trivial modifications. Not cleanly, but it works.

I put my git repo on 

	kernel.org:/pub/software/editors/uemacs/uemacs.git

but it will take a moment to mirror out. 

The "readme" says non-commercial only, but I asked Daniel Lawrence if it 
was ok to include it in commercial distributions a long time ago, and he 
said yes. Sadly, I've lost that email, so I don't have any paper trail for 
that. So you should consider the readme binding.

> [Yes, there is some (perverse) fun in telling people you use the very same
>  editor than Linus Torvalds :-]> 

The thing is, it's not a wonderful editor. It's small, and good enough, 
but I really wished somebody wrote something that handled UTF-8, for 
example.  But I've got the keybindings hardcoded in my spine, so I can't 
ever change.

		Linus

Re: [howto] Kernel hacker's guide to git, updated

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> I put my git repo on 
>
> 	kernel.org:/pub/software/editors/uemacs/uemacs.git
>
> but it will take a moment to mirror out. 

Wouldn't underneath pub/scm/ be more appropriate and gitweb
friendly?

> The thing is, it's not a wonderful editor. It's small, and good enough, 
> but I really wished somebody wrote something that handled UTF-8, for 
> example.

Hmph.  I vaguely recall in my distant past when I was still in
school, I did my own Japanization of microEmacs.  I wonder if
yours share the same root -- I do not have the source of my
version anymore so I have no way checking which ancient version
I mucked with.

Re: [howto] Kernel hacker's guide to git, updated

[Linus Torvalds]

On Thu, 29 Sep 2005, Junio C Hamano wrote:
> 
> Wouldn't underneath pub/scm/ be more appropriate and gitweb
> friendly?

Well, I don't actually have write permissions to anything there except for 
udner the kernel tree. Also, I suspect there aren't all that many uemacs 
users out there, and anybody who isn't already a uemacs user probably 
shouldn't pick it up.

I don't think it has gotten any real development for the last ten years, 
and while it was arguably the best editor twenty years ago (not a lot of 
competition - what else worked on DOS, VMS and UNIX without being crazy 
and modal?) it's definitely showing its age.

So since I already had a uemacs subdirectory, I just put the git archive 
there too.

> Hmph.  I vaguely recall in my distant past when I was still in
> school, I did my own Japanization of microEmacs.  I wonder if
> yours share the same root -- I do not have the source of my
> version anymore so I have no way checking which ancient version
> I mucked with.

It's based on 3.9e, with some fixes by Petri Kutvonen at Helsinki 
University. With various (slight) modernizations by yours truly (eg posix 
termios support rather than the old "termio" stuff).

It _shouldn't_ be that hard to teach it about UTF-8, but every time I look 
at it I realize that there is a lot of stuff that should be improved. 
Converting it to K&R, getting rid of the things that made sense in the 
80's but haven't made sense in ten years, re-indenting it (right now 
it's a strange mix of indentation styles)..

And if you open a binary file with it, it will literally spew binary 
characters to the tty, and can seriously confuse it due to the control 
chars. Or if you have a really long line, it can SIGSEGV on you. Cute.

But dammit, I'm not giving it up.

			Linus

Re: [howto] Kernel hacker's guide to git, updated

[Junio C Hamano]

Oliver Neukum <oliver@neukum.org> writes:

> Am Donnerstag, 29. September 2005 21:34 schrieb Jon Loeliger:
>> On Thu, 2005-09-29 at 14:08, Oliver Neukum wrote:
>> 
>> > Unfortunately, following the instructions to the letter produces this:
>> > oliver@oenone:~/linux-2.6> git checkout
>> > usage: read-tree (<sha> | -m <sha1> [<sha2> <sha3>])
>> 
>> Yeah.  See if you still have a .git/HEADS that symlinks
>> to a valid place or not...?
>
> oliver@oenone:~/linux-2.6> ls -la .git/
> insgesamt 14
> drwxrwxr-x    6 oliver users  224 2005-09-29 21:06 .
> drwxr-xr-x    3 oliver users   72 2005-09-29 20:45 ..
> -rw-rw-r--    1 oliver users   19 2005-05-02 01:02 description
> lrwxrwxrwx    1 oliver users   17 2005-09-29 21:06 HEAD -> refs/heads/master
> -rw-------    1 oliver users   32 2005-09-29 21:06 index

I wonder what that 32-byte small file called 'index' is doing
there.  If this is the kernel tree, its index file should weigh
about 1.7MB if I recall correctly.

Re: [howto] Kernel hacker's guide to git, updated

[Oliver Neukum]

Am Freitag, 30. September 2005 09:37 schrieb Junio C Hamano:
> Oliver Neukum <oliver@neukum.org> writes:
> 
> > Am Donnerstag, 29. September 2005 21:34 schrieb Jon Loeliger:
> >> On Thu, 2005-09-29 at 14:08, Oliver Neukum wrote:
> >> 
> >> > Unfortunately, following the instructions to the letter produces this:
> >> > oliver@oenone:~/linux-2.6> git checkout
> >> > usage: read-tree (<sha> | -m <sha1> [<sha2> <sha3>])
> >> 
> >> Yeah.  See if you still have a .git/HEADS that symlinks
> >> to a valid place or not...?
> >
> > oliver@oenone:~/linux-2.6> ls -la .git/
> > insgesamt 14
> > drwxrwxr-x    6 oliver users  224 2005-09-29 21:06 .
> > drwxr-xr-x    3 oliver users   72 2005-09-29 20:45 ..
> > -rw-rw-r--    1 oliver users   19 2005-05-02 01:02 description
> > lrwxrwxrwx    1 oliver users   17 2005-09-29 21:06 HEAD -> refs/heads/master
> > -rw-------    1 oliver users   32 2005-09-29 21:06 index
> 
> I wonder what that 32-byte small file called 'index' is doing
> there.  If this is the kernel tree, its index file should weigh
> about 1.7MB if I recall correctly.

I have no idea, but the instructions as stated didn't work for me.
Can you replicate that?

	Regards
		Oliver

Re: [howto] Kernel hacker's guide to git, updated

[Jeff Garzik]

Thanks for all the comments.  I just updated the KHGtG with the feedback 
I received.  Go to

	http://linux.yyz.us/git-howto.html

and click reload.  Continued criticism^H^H^Hcomments welcome!



Two items of note:

1)
> automatically.  Running the following one-liner every once in a
> while would sync your set of tags with Linus:
> 
> git fetch origin `git-ls-remote --tags origin | sed -ne 's|^.*refs/tags/|tag |p'`

that's way too long and convoluted to deal with.  Once the 'git fetch 
--tags' changes make it into the official repository (are they there 
already?), I'll remove all the remaining direct references to running rsync.


2) What is the easiest way to obtain a list of changes present in 
repository B, that are not present in repository A?  I used to use 
git-changes-script [hacked cg-log script] for this:

	$ cd /repo/netdev-2.6
	$ git-changes-script -L ../linux-2.6

would display all changes in /repo/netdev-2.6 which are not present in 
/repo/linux-2.6.  This is similar to 'git log master..HEAD', except for 
repositories rather than branches.

	Jeff

Re: [howto] Kernel hacker's guide to git, updated

[Junio C Hamano]

Jeff Garzik <jgarzik@pobox.com> writes:

> ...  Once the 'git fetch --tags' changes make it into the
> official repository (are they there already?), I'll remove all
> the remaining direct references to running rsync.

Sounds like a thinly veiled threat and/or very effective
prodding ;-).

It is not there yet only because I simply have not got around to
it, but it will happen before 0.99.8.

I suspect the version Linus posted has a funny interaction with
'git-pull'; 'git pull --tags' by mistake, or intentionally to
file a bug report to annoy me ;-), would create an Octopus out
of those tags, if I am not mistaken.

> 2) What is the easiest way to obtain a list of changes present in 
> repository B, that are not present in repository A?  I used to use 
> git-changes-script [hacked cg-log script] for this:

I think I still have the copy you sent to the list.  If you do
not mind me placing in the master branch just holler -- better
yet please send a patch with commit log and signoff to add the
latest, and I will apply it.

-jc

Re: [howto] Kernel hacker's guide to git, updated

[Oliver Neukum]

Am Freitag, 30. September 2005 13:15 schrieb Jeff Garzik:
> 
> Thanks for all the comments.  I just updated the KHGtG with the feedback 
> I received.  Go to
> 
> 	http://linux.yyz.us/git-howto.html
> 
> and click reload.  Continued criticism^H^H^Hcomments welcome!
> 

The error is still there.

oliver@oenone:~/linux-2.6> git checkout -f master
usage: read-tree (<sha> | -m <sha1> [<sha2> <sha3>])

	Regards
		Oliver

Re: [howto] Kernel hacker's guide to git, updated

[Erik Mouw]

On Fri, Sep 30, 2005 at 07:15:41AM -0400, Jeff Garzik wrote:
> >automatically.  Running the following one-liner every once in a
> >while would sync your set of tags with Linus:
> >
> >git fetch origin `git-ls-remote --tags origin | sed -ne 
> >'s|^.*refs/tags/|tag |p'`
> 
> that's way too long and convoluted to deal with.  Once the 'git fetch 
> --tags' changes make it into the official repository (are they there 
> already?), I'll remove all the remaining direct references to running rsync.

FYI, the rsync command to get the tags blows away .git/branches/origin,
so on the next "git pull", git will tell you "Where do you want to
fetch from today?".

In the mean time, better make it two separate rsync commands (sorry for
the long lines):

rsync -a --delete --verbose --stats --progress \
  rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/tags/ \
  .git/tags/

rsync -a --delete --verbose --stats --progress \
  rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/heads/ \
  .git/heads/


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

Re: [howto] Kernel hacker's guide to git, updated

[Johannes Schindelin]

Hi,

On Thu, 29 Sep 2005, Junio C Hamano wrote:

> Anton Altaparmakov <aia21@cam.ac.uk> writes:
> 
> > On Thu, 29 Sep 2005, Linus Torvalds wrote:
> >> On Thu, 29 Sep 2005, Dave Jones wrote:
> >> > What I find amusing is that it was a patch rejection mail from you
> >> > *years* back (circa 2000 iirc), telling me my pine corrupted whitespace,
> >> > that made me switch MUA ;-)
> >> > 
> >> > All these years later, and it's still buggered ?
> >> 
> >> Actually, it seems better. It seems to be buggered by default, but it used 
> >> to be that you had to actually recompile pine to make it behave. Now you 
> >> can just disable "strip-whitespace-before-send" and _enable_ 
> >> "quell-flowed-text" and those together seem to do the trick. No extra 
> >> patches or recompiles necessary.
> >
> > Indeed.  I use those two options like that, too.  (-:
> 
> Anybody interested in adding entry to SubmittingPatches MUA
> Specific Help section?

Did I miss something? Straight from my local git directory:

-- snip --

Pine
----

(Johannes Schindelin)

I don't know how many people still use pine, but for those poor
souls it may be good to mention that the quell-flowed-text is
needed for recent versions.

... the "no-strip-whitespace-before-send" option, too. AFAIK it
was introduced in 4.60.

-- snap --

Hth,
Dscho

Re: [howto] Kernel hacker's guide to git, updated

[Jeff Garzik]

Oliver Neukum wrote:
> Am Freitag, 30. September 2005 13:15 schrieb Jeff Garzik:
> 
>>Thanks for all the comments.  I just updated the KHGtG with the feedback 
>>I received.  Go to
>>
>>	http://linux.yyz.us/git-howto.html
>>
>>and click reload.  Continued criticism^H^H^Hcomments welcome!
>>
> 
> 
> The error is still there.
> 
> oliver@oenone:~/linux-2.6> git checkout -f master
> usage: read-tree (<sha> | -m <sha1> [<sha2> <sha3>])

Something's wrong with your installation, not the instructions.  Works 
fine here.

	Jeff

Re: [howto] Kernel hacker's guide to git, updated

[Jeff Garzik]

Erik Mouw wrote:
> FYI, the rsync command to get the tags blows away .git/branches/origin,
> so on the next "git pull", git will tell you "Where do you want to
> fetch from today?".

Agreed, though I always run 'git pull $url' each time, so I never 
noticed this.

Since git clone pulls the tags, I have eliminated the first rsync 
completely.

	Jeff

Re: [howto] Kernel hacker's guide to git, updated

[Jeff Garzik]

Junio C Hamano wrote:
> Jeff Garzik <jgarzik@pobox.com> writes:
>>2) What is the easiest way to obtain a list of changes present in 
>>repository B, that are not present in repository A?  I used to use 
>>git-changes-script [hacked cg-log script] for this:
> 
> 
> I think I still have the copy you sent to the list.  If you do
> not mind me placing in the master branch just holler -- better
> yet please send a patch with commit log and signoff to add the
> latest, and I will apply it.

It's archived here:
http://www.kernel.org/pub/linux/kernel/people/jgarzik/git-changes-script

but it needs a git expert (read: not me :)) to fix it up for the very 
latest git-core stuff.

Currently, using 'git-changes-script -L ../linux-2.6' spits out
> --------------------------
> commit 2fca877b68b2b4fc5b94277858a1bedd46017cde
> usage: git-cat-file [-t | -s | <type>] <sha1>
> 
> --------------------------
> commit ff40c6d3d1437ecdf295b8e39adcb06c3d6021ef
> usage: git-cat-file [-t | -s | <type>] <sha1>
> 
> --------------------------
> commit 8bf62ecee58360749c5f0e68bc97d5e02a6816b1
> usage: git-cat-file [-t | -s | <type>] <sha1>
> 
> --------------------------

Regards,

	Jeff

Re: [howto] Kernel hacker's guide to git, updated

[Alberto Patino]

On 9/30/05, Jeff Garzik <jgarzik@pobox.com> wrote:
> Oliver Neukum wrote:
> >
> > The error is still there.
> >
> > oliver@oenone:~/linux-2.6> git checkout -f master
> > usage: read-tree (<sha> | -m <sha1> [<sha2> <sha3>])
>
> Something's wrong with your installation, not the instructions.  Works
> fine here.
>

Right , you must have a corrupted copy of the git repo. Do the initial
cloning of the linux repository again, and then retry the git
checkout.

Re: [howto] Kernel hacker's guide to git, updated

[Linus Torvalds]

On Fri, 30 Sep 2005, Junio C Hamano wrote:
> 
> I wonder what that 32-byte small file called 'index' is doing
> there.  If this is the kernel tree, its index file should weigh
> about 1.7MB if I recall correctly.

32 bytes is what you get for an empty index (it's a 12-byte header, 
followed by a 20-byte SHA1 of the contents).

In general, such an index file it should be 100% equivalent to not having 
an index file at all.

		Linus

Re: [howto] Kernel hacker's guide to git, updated

[Horst von Brand]

Jeff Garzik <jgarzik@pobox.com> wrote:
> Thanks for all the comments.  I just updated the KHGtG with the
> feedback I received.  Go to
> 
> 	http://linux.yyz.us/git-howto.html
> 
> and click reload.  Continued criticism^H^H^Hcomments welcome!

- To know the current branch, "git branch" is enough (the one '*'-ed)
- rsync(1) a repository is dangerous, it might catch it in the middle of
  a update and give you an incomplete/messed up copy. Repeat rsync until no
  change, perhaps?
- I understand "git checkout -f" blows away any local changes, no questions
  asked. Not very nice to suggest that to a newbie...

Thanks for the docu!
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [howto] Kernel hacker's guide to git, updated

[Linus Torvalds]

On Fri, 30 Sep 2005, Junio C Hamano wrote:
> 
> I suspect the version Linus posted has a funny interaction with
> 'git-pull'; 'git pull --tags' by mistake, or intentionally to
> file a bug report to annoy me ;-), would create an Octopus out
> of those tags, if I am not mistaken.

Hey, even more impressive is "git pull --all", which will happily try to 
create an octopus of every single ref available at the other end.

Now, I think that octopus merges in _general_ are likely to be driver 
error, and that it might make sense to have a separate flag to enable 
them in the first place. That would solve the confusion..

So then you could do

	git pull --all --octopus xyzzy

if you _really_ meant to do that. 

		Linus

Re: [howto] Kernel hacker's guide to git, updated

[Francois Romieu]

Jeff Garzik <jgarzik@pobox.com> :
[...]
> Thanks for all the comments.  I just updated the KHGtG with the feedback 
> I received.  Go to
> 
> 	http://linux.yyz.us/git-howto.html
> 
> and click reload.  Continued criticism^H^H^Hcomments welcome!

The basic tasks make no use of git-whatchanged.

Even if it is a CVSism, it is quite handful to retrieve the history of
the patchsets by aiming at a specific file.

--
Ueimor

Re: [howto] Kernel hacker's guide to git, updated

[Linus Torvalds]

On Thu, 29 Sep 2005, Linus Torvalds wrote:
> 
> I put my git repo on 
> 
> 	kernel.org:/pub/software/editors/uemacs/uemacs.git

Gaah. You guys shamed me into actually trying to clean up the sources a 
bit.

It's by no means done, but some of it is even sparse-clean now.

I suspect there's a lot of it that still works mainly by luck than because 
it does anything right.

		Linus

Re: [howto] Kernel hacker's guide to git, updated

[Jeff Garzik]

Horst von Brand wrote:
> Jeff Garzik <jgarzik@pobox.com> wrote:
> 
>>Thanks for all the comments.  I just updated the KHGtG with the
>>feedback I received.  Go to
>>
>>	http://linux.yyz.us/git-howto.html
>>
>>and click reload.  Continued criticism^H^H^Hcomments welcome!
> 
> 
> - To know the current branch, "git branch" is enough (the one '*'-ed)

Click reload, this is already mentioned.


> - rsync(1) a repository is dangerous, it might catch it in the middle of
>   a update and give you an incomplete/messed up copy. Repeat rsync until no
>   change, perhaps?

Usually that's just unlucky.  I have caught kernel.org in the middle of 
a sync once, maybe twice.


> - I understand "git checkout -f" blows away any local changes, no questions
>   asked. Not very nice to suggest that to a newbie...

I constantly run into problems if I -do not- use the "-f" flag.  I 
habitually use it at all times, now.

Thanks,

	Jeff

Re: [howto] Kernel hacker's guide to git, updated

[Horst von Brand]

Linus Torvalds <torvalds@osdl.org> wrote:
> On Thu, 29 Sep 2005, Linus Torvalds wrote:
> > 
> > I put my git repo on 
> > 
> > 	kernel.org:/pub/software/editors/uemacs/uemacs.git
> 
> Gaah. You guys shamed me into actually trying to clean up the sources a 
> bit.

I'd been trying my hand at the original version. Need to merge my changes
with yours...
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: [howto] Kernel hacker's guide to git, updated

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> Hey, even more impressive is "git pull --all", which will happily try to 
> create an octopus of every single ref available at the other end.

True.

However, I think --all is a mistake even if you use it without
merging in 'git fetch', so I am not planning to do refs/heads/
side, at least not yet.  Even if you prevent an Octopus, what
would you do then?  If you choose to merge one of them, which
one?  Not merging any that is not explicitly specified on the
command line, seems to me the most sensible and safe option.

The rule for 'pull' to decide which refs to merge is:

 (1) if command line has explicit refspecs (--tags and --heads
     do not count), they are all merged.

 (2) if command line has no explicit refspecs (--tags and
     --heads do not count), the default one found from either
     remotes or branches file is merged.

Notice that I am forbidding remotes file to say "by default I
always merge these three heads from there to make an Octopus" by
the above rule (branches file cannot even name more than one
head so this is not an issue).  Since everybody seems to agree
that Octopus is not something that is done mechanically and
routinely anyway [*1*], I think this is a sensible way to guard
against accidental Octopus.

We could consider fetching all heads, by minimally renaming
remote master to origin and getting everything else under the
same name, but I'd really want to keep the local namespace for
branches isolated from each other.  Many kernel.org public
repositories seem to have 'test' and 'release' branches and if
you are a maintainer of such a tree, and if you are interested
in another maintainer's tree, and if that other maintainer has
the 'test' and 'release' branches, --heads (or --tags)
overwriting your 'test' with his 'test' is obviously not what
you want.

Possibly, something like this could be arranged later:

	* git fetch --heads=$ns $remote "$@"

	In addition to the usual refspecs (the rest of the
	command line arguments), fetch all remote heads and
	store remote refs/heads/$a under local refs/heads/$ns/$a
	for all $a.  If $ns is empty, remote "master" is renamed
	"origin".

	* git fetch --heads $remote "$@"

        shorthand for empty $ns

[Footnote]

*1* I do make many Octopus merges, but they happen across my
local topic branches.  Topics merged change day-by-day, and even
the set of topics alive at the time changes everyday.  IOW, it
is not something I would want to do with the same sets of heads
every time by describing them in the remotes file.

Re: [howto] Kernel hacker's guide to git, updated

[Junio C Hamano]

Jeff Garzik <jgarzik@pobox.com> writes:

> Junio C Hamano wrote:
>> Jeff Garzik <jgarzik@pobox.com> writes:

>>> 2) What is the easiest way to obtain a list of changes present in
>>> repository B, that are not present in repository A?  I used to use
>>> git-changes-script [hacked cg-log script] for this:

I haven't really *read* that script, but I think it is trying to
make a list of commits from both repositories and trying to find
the set that are in one side and not in the other using diff (a
real shell programer probably would have used "comm" for this
kind of task, not "diff"), then doing a handcrafted git-log on
each of them.

Attached is my quick hack, based on your original question,
without really trying to understand what the script is doing, so
I cannot claim it is a rewrite nor even attempting to be
compatible.  Please take a look at it and tell me if this is
any close to what you need.

I have a suspition that this might be better done as a natural
extension of git-log, though.

------------
#!/bin/sh
#
# Copyright (c) 2005 Junio C Hamano
#

. git-sh-setup || die "Not a git archive"

usage () {
	echo >&2 "$0 ( -L | -R ) <dir> [<ref>] [<ref>]

-L shows changes in local not in remote.
-R shows changes in remote not in local.
<dir> names the remote repository.

If given no refs, local and remote HEADs are compared.
If given one ref, local HEAD and named remote ref are compared.
If given two refs, the first names a local ref, and the second names
remote ref to be compared.
"
	exit 1
}

case "$1" in
-L | -R)
	;;
*)
	usage ;;
esac

other="$2"

(
	unset GIT_DIR GIT_OBJECT_DIRECTORY
	cd "$other" && . git-sh-setup ||
	die "$other is not a valid git repository."
)

local=${3:-HEAD}
remote=${4:-HEAD}

# Basic validation.
local=$(git-rev-parse --verify "$local^0" 2>/dev/null) ||
die "local ref $local is not valid."
remote=$(GIT_DIR="$other" git-rev-parse --verify "$remote^0" 2>/dev/null) ||
die "remote ref $remote is not valid."

case "$1" in
-L)
	list_args="$local ^$remote" ;;
-R)
	list_args="^$local $remote" ;;
esac

GAOD="$GIT_ALTERNATE_OBJECT_DIRECTORIES"

GIT_ALTERNATE_OBJECT_DIRECTORIES="$other/.git/objects:$GAOD" \
git-rev-list --pretty $list_args |
LESS=-S ${PAGER:-less}

Re: [howto] Kernel hacker's guide to git, updated

[Linus Torvalds]

[ Sorry about the spam, most of you probably have never cared ]

On Fri, 30 Sep 2005, Horst von Brand wrote:
> 
> I'd been trying my hand at the original version. Need to merge my changes
> with yours...

Heh, now that I got into cleaning things up, I've also been actually 
fixing things that have long irritated me, but the code was just too messy 
for me, and my level of care wasn't high enough to overcome.

I fixed the "outputs binary data in the 128-159 range to the terminal" 
yesterday (which would quite possibly corrupt terminal state if trying to 
edit binary files), and today I added a "utf-8" mode.

The utf-8 mode is purely about the _terminal_ being in UTF-8. The actual 
editor is still very much byte-char based, but now it understands 8-bit 
input that comes in UTF8-encoded, and can output things in UTF-8 format. 

(Since UTF-8 is basically always used with Unicode, and the 8-bit subset 
of Unicode is iso-8859-1 aka Latin1, this is probably _less_ international 
than the non-UTF8, but hey, what can I say? If you want more, you'd need 
to teach uemacs about actual UTF8 contents).

The new "emacs.rc" will enable utf-8 mode automatically if $LANG contains 
the substring "UTF-8", since that _usually_ means that the terminal is in 
utf-8 mode. If it's wrong, you can add or delete the mode by hand (just 
like any global mode: Meta-X to add, Meta-Ctrl-X to delete).

Basically, it means that you don't have to switch the whole terminal into 
latin1 just to use uemacs.

			Linus