LinuxLists.cc - [howto] Kernel hacker's guide to git, updated

[permalink] [raw]

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

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

2005-09-29 20:07:37

by Anton Altaparmakov

[permalink] [raw]

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

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/

2005-09-29 20:11:45

[permalink] [raw]

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

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

2005-09-29 20:15:49

[permalink] [raw]

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

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

2005-09-29 21:15:01

[permalink] [raw]

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

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"

2005-09-29 21:23:07

by Chuck Lever

[permalink] [raw]

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

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/ ...

Attachments:

cel.vcf (439.00 B)

2005-09-29 21:26:57

[permalink] [raw]

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

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

2005-09-29 21:33:36

[permalink] [raw]

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

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

2005-09-29 21:33:18

by Elfyn McBratney

[permalink] [raw]

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

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

Attachments:

(No filename) (673.00 B)
(No filename) (189.00 B)
Download all attachments

2005-09-29 21:36:17

[permalink] [raw]

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

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"

2005-09-29 21:40:54

[permalink] [raw]

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

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

2005-09-29 21:56:06

[permalink] [raw]

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

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

2005-09-29 22:12:49

by Anton Altaparmakov

[permalink] [raw]

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

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/

2005-09-29 22:29:05

[permalink] [raw]

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

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

2005-09-29 22:33:08

by Anton Altaparmakov

[permalink] [raw]

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

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/

2005-09-29 23:39:52

by Horst H. von Brand

[permalink] [raw]

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

Linus Torvalds <[email protected]> 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

2005-09-30 00:48:29

[permalink] [raw]

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

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

2005-09-30 11:16:04

[permalink] [raw]

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

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

2005-09-30 11:55:08

by Junio C Hamano

[permalink] [raw]

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

Jeff Garzik <[email protected]> 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

2005-09-30 12:03:04

by Oliver Neukum

[permalink] [raw]

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

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

2005-09-30 12:07:43

by Erik Mouw

[permalink] [raw]

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

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 -- http://www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands

2005-09-30 13:58:34

[permalink] [raw]

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

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

2005-09-30 14:08:57

[permalink] [raw]

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

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

2005-09-30 14:11:11

[permalink] [raw]

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

Junio C Hamano wrote:
> Jeff Garzik <[email protected]> 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

2005-09-30 15:10:58

by Alberto Patino

[permalink] [raw]

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

On 9/30/05, Jeff Garzik <[email protected]> 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.

2005-09-30 18:13:54

by Horst H. von Brand

[permalink] [raw]

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

Jeff Garzik <[email protected]> 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

2005-09-30 18:14:32

[permalink] [raw]

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

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

2005-10-01 00:17:31