threads / discuss / 6100

Re: Updated Kernel Hacker's guide to git

Subject: Re: Updated Kernel Hacker's guide to git

## tl;dr

19 messages between Dec 24, 2006 and Jul 3, 2008.

replies: 18people: 11as markdown or json

Horst H. von Brand· Dec 24, 2006, 18:07 UTC · lore
Jeff Garzik <jeff@garzik.org> wrote:
> I refreshed my git intro/cookbook for kernel hackers, at
> http://linux.yyz.us/git-howto.html
Looks nice, starting to look it over.
Notes:
Getting started:
  There are RPM packages available (I think they are for latest Fedora; in
  case of doubt get the latest SRPM and build yourself, sometimes the
  distros lag /way/ behind). There are also Debian packages there, dunno
  about those.
Basic tasks:
  'git pull' should be enough, no need to give the URL each time.
  It is useful to tell people how to get "nonofficial" branches (via URL +
  branches) too.
  
Miscellaneous debris:
  'git pull' has gotten tags each time for me?
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile               Fax:  +56 32 2797513
Jeff Garzik· Dec 23, 2007, 11:13 UTC · re: Horst H. von Brand · lore

Updated Kernel Hacker's guide to git

Another year, another update!  :)
The kernel hacker's guide to git has received some updates:
	http://linux.yyz.us/git-howto.html

This includes all the input sent to me in the past several months, as well as a few new tips and tricks I use on a regular basis.

In general, this document is designed to be a quick-start cookbook, and not a comprehensive introduction.

Merry Christmas and Happy Holidays to all!
	Jeff
Robert P. J. Day· Dec 23, 2007, 12:08 UTC · re: Jeff Garzik · lore
On Sun, 23 Dec 2007, Jeff Garzik wrote:
Show 11 quoted lines
> Another year, another update!  :)
>
> The kernel hacker's guide to git has received some updates:
>
> 	http://linux.yyz.us/git-howto.html
>
> This includes all the input sent to me in the past several months,
> as well as a few new tips and tricks I use on a regular basis.
>
> In general, this document is designed to be a quick-start cookbook,
> and not a comprehensive introduction.

there's one issue i have with this document, and that's that i wish it more carefully distinguished between regular git "user" tasks, and git "developer" tasks.

i may be mistaken, but it would seem that a lot of folks are going to be what i call basic users, who only want to update their git tree, check the logs, check the status and so on. and if they start to get ambitious, they might make some changes to the tree, do a diff, and submit a patch. but in the beginning, they won't be making commits or switching branches, etc.

in short, i can see the value of something like a "getting started with git as a basic user" tutorial. does such a thing exist?

rday --

======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA

http://crashcourse.ca ========================================================================

Jeff Garzik· Dec 23, 2007, 12:13 UTC · re: Robert P. J. Day · lore
Robert P. J. Day wrote:
Show 27 quoted lines
> On Sun, 23 Dec 2007, Jeff Garzik wrote:
> 
>> Another year, another update!  :)
>>
>> The kernel hacker's guide to git has received some updates:
>>
>> 	http://linux.yyz.us/git-howto.html
>>
>> This includes all the input sent to me in the past several months,
>> as well as a few new tips and tricks I use on a regular basis.
>>
>> In general, this document is designed to be a quick-start cookbook,
>> and not a comprehensive introduction.
> 
> there's one issue i have with this document, and that's that i wish it
> more carefully distinguished between regular git "user" tasks, and git
> "developer" tasks.
> 
> i may be mistaken, but it would seem that a lot of folks are going to
> be what i call basic users, who only want to update their git tree,
> check the logs, check the status and so on.  and if they start to get
> ambitious, they might make some changes to the tree, do a diff, and
> submit a patch.  but in the beginning, they won't be making commits or
> switching branches, etc.
> 
> in short, i can see the value of something like a "getting started
> with git as a basic user" tutorial.  does such a thing exist?

hmmm. There's the tutorial linked at the bottom of the page, which in turn links to http://www.kernel.org/pub/software/scm/git/docs/everyday.html

git is a developer's tool, so I sorta targetted that audience. I definitely agree that is not only git audience...

	Jeff
Robert P. J. Day· Dec 23, 2007, 12:20 UTC · re: Jeff Garzik · lore
On Sun, 23 Dec 2007, Jeff Garzik wrote:
Show 35 quoted lines
> Robert P. J. Day wrote:
> > On Sun, 23 Dec 2007, Jeff Garzik wrote:
> >
> > > Another year, another update!  :)
> > >
> > > The kernel hacker's guide to git has received some updates:
> > >
> > > 	http://linux.yyz.us/git-howto.html
> > >
> > > This includes all the input sent to me in the past several months,
> > > as well as a few new tips and tricks I use on a regular basis.
> > >
> > > In general, this document is designed to be a quick-start cookbook,
> > > and not a comprehensive introduction.
> >
> > there's one issue i have with this document, and that's that i wish it
> > more carefully distinguished between regular git "user" tasks, and git
> > "developer" tasks.
> >
> > i may be mistaken, but it would seem that a lot of folks are going to
> > be what i call basic users, who only want to update their git tree,
> > check the logs, check the status and so on.  and if they start to get
> > ambitious, they might make some changes to the tree, do a diff, and
> > submit a patch.  but in the beginning, they won't be making commits or
> > switching branches, etc.
> >
> > in short, i can see the value of something like a "getting started
> > with git as a basic user" tutorial.  does such a thing exist?
>
> hmmm.  There's the tutorial linked at the bottom of the page, which
> in turn links to
> http://www.kernel.org/pub/software/scm/git/docs/everyday.html
>
> git is a developer's tool, so I sorta targetted that audience.  I
> definitely agree that is not only git audience...

just to be clear, i'm not complaining about the quality of the document above, but when i got started with git, what i really wanted was a list of what i (as a simple, non-developer user) could do once i cloned a repository.

to that end, i put together my own little reference list of git commands. for example, i collected ways to examine my repository -- git commands like branch, tag, log/shortlog, what-changed, show, grep, blame, that sort of thing. exactly the kind of stuff a new user might want to know about, even without the ability to change anything.

just my $0.02.

rday --

======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA

http://crashcourse.ca ========================================================================

Dieter Ries· Dec 23, 2007, 13:05 UTC · re: Robert P. J. Day · lore
Robert P. J. Day schrieb:
Show 46 quoted lines
> On Sun, 23 Dec 2007, Jeff Garzik wrote:
> 
>> Robert P. J. Day wrote:
>>> On Sun, 23 Dec 2007, Jeff Garzik wrote:
>>>
>>>> Another year, another update!  :)
>>>>
>>>> The kernel hacker's guide to git has received some updates:
>>>>
>>>> 	http://linux.yyz.us/git-howto.html
>>>>
>>>> This includes all the input sent to me in the past several months,
>>>> as well as a few new tips and tricks I use on a regular basis.
>>>>
>>>> In general, this document is designed to be a quick-start cookbook,
>>>> and not a comprehensive introduction.
>>> there's one issue i have with this document, and that's that i wish it
>>> more carefully distinguished between regular git "user" tasks, and git
>>> "developer" tasks.
>>>
>>> i may be mistaken, but it would seem that a lot of folks are going to
>>> be what i call basic users, who only want to update their git tree,
>>> check the logs, check the status and so on.  and if they start to get
>>> ambitious, they might make some changes to the tree, do a diff, and
>>> submit a patch.  but in the beginning, they won't be making commits or
>>> switching branches, etc.
>>>
>>> in short, i can see the value of something like a "getting started
>>> with git as a basic user" tutorial.  does such a thing exist?
>> hmmm.  There's the tutorial linked at the bottom of the page, which
>> in turn links to
>> http://www.kernel.org/pub/software/scm/git/docs/everyday.html
>>
>> git is a developer's tool, so I sorta targetted that audience.  I
>> definitely agree that is not only git audience...
> 
> just to be clear, i'm not complaining about the quality of the
> document above, but when i got started with git, what i really wanted
> was a list of what i (as a simple, non-developer user) could do once i
> cloned a repository.
> 
> to that end, i put together my own little reference list of git
> commands.  for example, i collected ways to examine my repository --
> git commands like branch, tag, log/shortlog, what-changed, show, grep,
> blame, that sort of thing.  exactly the kind of stuff a new user might
> want to know about, even without the ability to change anything.

Could you perhaps publish your reference list as kind of a christmas gift to all basic users like me?

cu Dieter

ps.: sorry for sending this twice, messed up recipients.
Show 19 quoted lines
> 
> just my $0.02.
> 
> rday
> --
> 
> ========================================================================
> Robert P. J. Day
> Linux Consulting, Training and Annoying Kernel Pedantry
> Waterloo, Ontario, CANADA
> 
> http://crashcourse.ca
> ========================================================================
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
Robert P. J. Day· Dec 23, 2007, 17:23 UTC · re: Dieter Ries · lore
On Sun, 23 Dec 2007, Dieter Ries wrote:
> Robert P. J. Day schrieb:
Show 14 quoted lines
> > just to be clear, i'm not complaining about the quality of the
> > document above, but when i got started with git, what i really
> > wanted was a list of what i (as a simple, non-developer user)
> > could do once i cloned a repository.
> >
> > to that end, i put together my own little reference list of git
> > commands.  for example, i collected ways to examine my repository
> > -- git commands like branch, tag, log/shortlog, what-changed,
> > show, grep, blame, that sort of thing.  exactly the kind of stuff
> > a new user might want to know about, even without the ability to
> > change anything.
>
> Could you perhaps publish your reference list as kind of a christmas
> gift to all basic users like me?

if you give me a day or two (or three), i may put an updated version of that up on my wiki.

rday

======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA

http://crashcourse.ca ========================================================================

Stefan Richter· Dec 23, 2007, 20:14 UTC · re: Dieter Ries · lore
Dieter Ries wrote:
Show 13 quoted lines
> Robert P. J. Day schrieb:
>> when i got started with git, what i really wanted
>> was a list of what i (as a simple, non-developer user) could do once i
>> cloned a repository.
>>
>> to that end, i put together my own little reference list of git
>> commands.  for example, i collected ways to examine my repository --
>> git commands like branch, tag, log/shortlog, what-changed, show, grep,
>> blame, that sort of thing.  exactly the kind of stuff a new user might
>> want to know about, even without the ability to change anything.
> 
> Could you perhaps publish your reference list as kind of a christmas
> gift to all basic users like me?

Here are three out of four things which I do frequently with git repos: I look at

  - commits and blobs in other people's trees with gitweb,
  - commits in a local tree with gitk,
  - specific changes to source code with qgit, using it as "git blame"
    GUI.

(The fourth thing is feeding a driver subsystem git tree at kernel.org using a minimum number of git commands. Everything else which I do with git I do so infrequently that I have to reread manuals all the time.)

-- 
Stefan Richter
-=====-=-=== ==-- =-===
http://arcgraph.de/sr/
Robert P. J. Day· Dec 24, 2007, 14:19 UTC · re: Dieter Ries · lore
On Sun, 23 Dec 2007, Dieter Ries wrote:
> Could you perhaps publish your reference list as kind of a christmas
> gift to all basic users like me?
FYI, i'm typing in my own reference list as we speak here:
  http://www.crashcourse.ca/wiki/index.php/Git

still quite a bit to go, but you can get the overall idea. new sections should be appearing there as the morning progresses.

rday

======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA

http://crashcourse.ca ========================================================================

WANG Cong· Dec 23, 2007, 12:25 UTC · re: Jeff Garzik · lore
On Sun, Dec 23, 2007 at 06:13:03AM -0500, Jeff Garzik wrote:
Show 11 quoted lines
>Another year, another update!  :)
>
>The kernel hacker's guide to git has received some updates:
>
>	http://linux.yyz.us/git-howto.html
>
>This includes all the input sent to me in the past several months, as 
>well as a few new tips and tricks I use on a regular basis.
>
>In general, this document is designed to be a quick-start cookbook, and 
>not a comprehensive introduction.
Jeff, very good! I like it. Thank you! ;-)
>
>Merry Christmas and Happy Holidays to all!
>
Merry Christmas, kernel hackers!
Best wishes!
Miklos Vajna· Dec 24, 2007, 12:50 UTC · re: Jeff Garzik · lore
On Sun, Dec 23, 2007 at 06:13:03AM -0500, Jeff Garzik <jeff@garzik.org> wrote:
Show 5 quoted lines
> Another year, another update!  :)
> 
> The kernel hacker's guide to git has received some updates:
> 
> 	http://linux.yyz.us/git-howto.html
one minor note:
i would suggest using:
$ git shortlog master..HEAD
instead of
$ git log master..HEAD | git shortlog
to avoid unnecessary complexity :)
thanks,
- VMiklos
Salikh Zakirov· Dec 25, 2007, 13:08 UTC · re: Jeff Garzik · lore
Jeff Garzik wrote:
> The kernel hacker's guide to git has received some updates: 
> http://linux.yyz.us/git-howto.html

I have some comments on the contents, though I need to warn, that I've been following git development for about year and a half now, and I am not a kernel hacker, so my comments may have wrong bias.

Show 7 quoted lines
>     Obtain a diff between current branch, and master branch
> 
> In most trees with branches, .git/refs/heads/master contains the
> current 'vanilla' upstream tree, for easy diffing and merging. (in
> trees without branches, 'master' simply contains your latest changes)
> 
> $ git diff master..HEAD

IMHO, syntax 'git diff master HEAD' is preferable, in order to avoid confusion with 'git log master..HEAD' usage, which has quite different meaning, roughly expressible as

  git diff `git merge-base master HEAD` HEAD
for getting one big diff of the changes in HEAD since master)
> (this is equivalent to git diff HEAD, when used with HEAD branch)

This seems incorrect to me, as 'git diff master HEAD' compares two revisions, while 'git diff HEAD' compares working tree with HEAD revision.

Besides, expression 'HEAD branch' is misleading, because HEAD is not a branch by itself, but rather a link to the latest state of the current branch.

Jan Engelhardt· Dec 31, 2007, 02:50 UTC · re: Jeff Garzik · lore
On Dec 23 2007 06:13, Jeff Garzik wrote:
Show 6 quoted lines
> Another year, another update!  :)
>
> The kernel hacker's guide to git has received some updates:
>
> 	http://linux.yyz.us/git-howto.html
>
It says
"""Don't forget to download tags from time to time.

git pull only downloads sha1-indexed object data, and the requested remote head. This misses updates to the .git/refs/tags/ and .git/refs/heads/ directories. For tags, run git fetch --tags $URL."""

But when I do git pull on a simple tracking tree (e.g. git-clone torvalds/linux-2.6.git; git pull;) it automatically grabs new tags.

Stefan Richter· Dec 31, 2007, 11:26 UTC · re: Jan Engelhardt · lore
Jan Engelhardt wrote:
Show 12 quoted lines
>> 	http://linux.yyz.us/git-howto.html
> 
> It says
> 
> """Don't forget to download tags from time to time.
> 
> git pull only downloads sha1-indexed object data, and the requested
> remote head. This misses updates to the .git/refs/tags/ and
> .git/refs/heads/ directories. For tags, run git fetch --tags $URL."""
> 
> But when I do git pull on a simple tracking tree (e.g. git-clone
> torvalds/linux-2.6.git; git pull;) it automatically grabs new tags.

A while ago the default behavior of git pull was changed to fetch all tags which point to objects that can be reached from any of the tracked heads.

Old behaviour: Option --tags was needed to fetch tags at all. Current behavior: Option --tags forces to download all tags and the objects they point to. Option --no-tags works like the old default behavior.

Readers of Kernel Hackers' Guide to git will most certainly have a recent enough version of git so that the "download_tags" subsection can be removed without replacement.

-- 
Stefan Richter
-=====-=-=== ==-- =====
http://arcgraph.de/sr/
Junio C Hamano· Dec 31, 2007, 17:31 UTC · re: Stefan Richter · lore
Stefan Richter <stefanr@s5r6.in-berlin.de> writes:
Show 25 quoted lines
> Jan Engelhardt wrote:
>>> 	http://linux.yyz.us/git-howto.html
>> 
>> It says
>> 
>> """Don't forget to download tags from time to time.
>> 
>> git pull only downloads sha1-indexed object data, and the requested
>> remote head. This misses updates to the .git/refs/tags/ and
>> .git/refs/heads/ directories. For tags, run git fetch --tags $URL."""
>> 
>> But when I do git pull on a simple tracking tree (e.g. git-clone
>> torvalds/linux-2.6.git; git pull;) it automatically grabs new tags.
>
> A while ago the default behavior of git pull was changed to fetch all
> tags which point to objects that can be reached from any of the tracked
> heads.
>
> Old behaviour:  Option --tags was needed to fetch tags at all.  Current
> behavior:  Option --tags forces to download all tags and the objects
> they point to.  Option --no-tags works like the old default behavior.
>
> Readers of Kernel Hackers' Guide to git will most certainly have a
> recent enough version of git so that the "download_tags" subsection can
> be removed without replacement.
All correct.

That "A while ago" is quite a while ago, though. IIRC it was added very early in 2006, which is eons ago in git timescale.

Jeff Garzik· Jun 30, 2008, 02:51 UTC · re: Stefan Richter · lore
Stefan Richter wrote:
Show 16 quoted lines
> Jan Engelhardt wrote:
>>> 	http://linux.yyz.us/git-howto.html
>> It says
>>
>> """Don't forget to download tags from time to time.
>>
>> git pull only downloads sha1-indexed object data, and the requested
>> remote head. This misses updates to the .git/refs/tags/ and
>> .git/refs/heads/ directories. For tags, run git fetch --tags $URL."""
>>
>> But when I do git pull on a simple tracking tree (e.g. git-clone
>> torvalds/linux-2.6.git; git pull;) it automatically grabs new tags.
> 
> A while ago the default behavior of git pull was changed to fetch all
> tags which point to objects that can be reached from any of the tracked
> heads.

This does not work in all cases. When I retrieve the latest kernel, it downloads the tags:

	cd /spare/repo/linux-2.6
	git pull

but when I pull those changes into another local repo, the tags do -not- follow the objects:

	cd /spare/repo/misc-2.6
	git checkout master
	git pull ../linux-2.6
	git fetch --tags ../linux-2.6	# still required to this day
Regards,
	Jeff
Stefan Richter· Jun 30, 2008, 06:27 UTC · re: Jeff Garzik · lore
Jeff Garzik wrote:
Show 19 quoted lines
> Stefan Richter wrote:
>> A while ago the default behavior of git pull was changed to fetch all
>> tags which point to objects that can be reached from any of the tracked
>> heads.
> 
> 
> This does not work in all cases.  When I retrieve the latest kernel, it 
> downloads the tags:
> 
>     cd /spare/repo/linux-2.6
>     git pull
> 
> but when I pull those changes into another local repo, the tags do -not- 
> follow the objects:
> 
>     cd /spare/repo/misc-2.6
>     git checkout master
>     git pull ../linux-2.6
>     git fetch --tags ../linux-2.6    # still required to this day

I guess this is because /spare/repo/misc-2.6 does not have branches of /spare/repo/linux-2.6 configured as remote (tracking) branches.

-- 
Stefan Richter
-=====-==--- -==- ====-
http://arcgraph.de/sr/
Jeff Garzik· Jun 30, 2008, 02:49 UTC · re: Jan Engelhardt · lore
Jan Engelhardt wrote:
Show 19 quoted lines
> On Dec 23 2007 06:13, Jeff Garzik wrote:
>> Another year, another update!  :)
>>
>> The kernel hacker's guide to git has received some updates:
>>
>> 	http://linux.yyz.us/git-howto.html
>>
> 
> It says
> 
> """Don't forget to download tags from time to time.
> 
> git pull only downloads sha1-indexed object data, and the requested
> remote head. This misses updates to the .git/refs/tags/ and
> .git/refs/heads/ directories. For tags, run git fetch --tags $URL."""
> 
> 
> But when I do git pull on a simple tracking tree (e.g. git-clone
> torvalds/linux-2.6.git; git pull;) it automatically grabs new tags.

Unfortunately tags are not copied in all cases. To this day, I still have to 'git fetch --tags', generally when pulling from one local repo into another. It's annoying that tags don't follow objects, when pulled.

	Jeff
Christian Couder· Jul 3, 2008, 06:26 UTC · re: Jeff Garzik · lore
Hi,
Le lundi 30 juin 2008, Jeff Garzik a écrit :
Show 7 quoted lines
> Jan Engelhardt wrote:
> > On Dec 23 2007 06:13, Jeff Garzik wrote:
> >> Another year, another update!  :)
> >>
> >> The kernel hacker's guide to git has received some updates:
> >>
> >> 	http://linux.yyz.us/git-howto.html

May I suggest adding some stuff about "git bisect", or at least links to other documentation about it, in this guide?

Especially, you may want to add an example about how to automate testing using "git bisect run" as you suggest other to do that:

http://www.ussg.iu.edu/hypermail/linux/kernel/0804.1/0633.html

Thanks in advance, Christian.

← back to recent threads