I refreshed my git intro/cookbook for kernel hackers, at
http://linux.yyz.us/git-howto.html
This describes most of the commands I use in day-to-day kernel hacking.
Let me know if there are glaring errors or missing key commands.
Jeff
Hi Jeff !
On Wed, Dec 20, 2006 at 10:04:17PM -0500, Jeff Garzik wrote:
> I refreshed my git intro/cookbook for kernel hackers, at
> http://linux.yyz.us/git-howto.html
Thanks for this update, it was my most useful source of inspiration
when I started with git.
> This describes most of the commands I use in day-to-day kernel hacking.
> Let me know if there are glaring errors or missing key commands.
I very often use "git-format-patch -k -m" to produce individual patches
that I delay, merge in other branches, or even in other trees with
"git-am -k -3". I believe it was Davem who suggested this a while ago,
and I agree it's very convenient to maintain a patch collection (and
sometimes to clean them up).
Also, I think that for beginners, you have not insisted enough on the
fact that they should not modify the master branch, but that they
should immediately create their own branch before any local changes.
I got caught by this when I started, and had trouble playing with the
origin branch to try to fix my mistakes.
Overall it's a good tutorial anyway.
Cheers,
Willy
Hi.
On Wed, 2006-12-20 at 22:04 -0500, Jeff Garzik wrote:
> I refreshed my git intro/cookbook for kernel hackers, at
> http://linux.yyz.us/git-howto.html
>
> This describes most of the commands I use in day-to-day kernel hacking.
> Let me know if there are glaring errors or missing key commands.
Thanks for the work! I'd suggest also saying how to repack and cleanup.
Could also be a good idea to go through the steps for uploading to
master.kernel.org or elsewhere?
Regards,
Nigel
Nigel Cunningham wrote:
> Hi.
>
> On Wed, 2006-12-20 at 22:04 -0500, Jeff Garzik wrote:
>> I refreshed my git intro/cookbook for kernel hackers, at
>> http://linux.yyz.us/git-howto.html
>>
>> This describes most of the commands I use in day-to-day kernel hacking.
>> Let me know if there are glaring errors or missing key commands.
>
> Thanks for the work! I'd suggest also saying how to repack and cleanup.
Yes, I should mention repacking. When you say cleanup, what
specifically do you mean?
> Could also be a good idea to go through the steps for uploading to
> master.kernel.org or elsewhere?
Yes, push should be mentioned at the very least.
Jeff
Jeff Garzik <[email protected]> :
> I refreshed my git intro/cookbook for kernel hackers, at
> http://linux.yyz.us/git-howto.html
>
> This describes most of the commands I use in day-to-day kernel hacking.
> Let me know if there are glaring errors or missing key commands.
o 'git whatchanged shnortz' can probably be replaced with
'git log -- schnortz' so there is one command less to remember.
o "Display changes since last git-update-index:"
Fine but you have not told the reader what git-update-index is.
--
Ueimor
On Wed, 20 Dec 2006, Jeff Garzik wrote:
> I refreshed my git intro/cookbook for kernel hackers, at
> http://linux.yyz.us/git-howto.html
Very nice, thanks! A couple of remarks from an absolute git newbie:
1. I heard "git am" is supposed to supersede apply-mbox
2. What I often have problems with is - what to do if git spits at me a
bunch of conflict messages after a seemingly safe pull or similar. Don't
know if you want to cover those points but "git troubleshooting" would
definitely be a valuable document.
Thanks
Guennadi
---
Guennadi Liakhovetski
Guennadi Liakhovetski wrote:
> On Wed, 20 Dec 2006, Jeff Garzik wrote:
>
>> I refreshed my git intro/cookbook for kernel hackers, at
>> http://linux.yyz.us/git-howto.html
>
> Very nice, thanks! A couple of remarks from an absolute git newbie:
>
> 1. I heard "git am" is supposed to supersede apply-mbox
Hey, that's pretty neat. Glad you told me, this should improve my
workflow a bit.
> 2. What I often have problems with is - what to do if git spits at me a
> bunch of conflict messages after a seemingly safe pull or similar. Don't
> know if you want to cover those points but "git troubleshooting" would
> definitely be a valuable document.
Agreed.
Jeff
Hi.
On Thu, 2006-12-21 at 06:44 -0500, Jeff Garzik wrote:
> Nigel Cunningham wrote:
> > Hi.
> >
> > On Wed, 2006-12-20 at 22:04 -0500, Jeff Garzik wrote:
> >> I refreshed my git intro/cookbook for kernel hackers, at
> >> http://linux.yyz.us/git-howto.html
> >>
> >> This describes most of the commands I use in day-to-day kernel hacking.
> >> Let me know if there are glaring errors or missing key commands.
> >
> > Thanks for the work! I'd suggest also saying how to repack and cleanup.
>
> Yes, I should mention repacking. When you say cleanup, what
> specifically do you mean?
Oh, I was just thinking of the related commands - prune-packed,
count-objects, fsck-objects and so on. (I know repack does prune-packed
when you use -d, but it might be handy to mention it anyway... or
not :>)
> > Could also be a good idea to go through the steps for uploading to
> > master.kernel.org or elsewhere?
>
> Yes, push should be mentioned at the very least.
Nigel
On 21/12/06, Jeff Garzik <[email protected]> wrote:
> I refreshed my git intro/cookbook for kernel hackers, at
> http://linux.yyz.us/git-howto.html
>
> This describes most of the commands I use in day-to-day kernel hacking.
> Let me know if there are glaring errors or missing key commands.
>
Very nice.
A bit on how to revert a commit and how to rebase a branch would make
it even nicer :)
Thank you for a very good document, Jeff.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
Jeff Garzik <[email protected]> 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
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
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?
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
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...
Jeff
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.
just my $0.02.
rday
--
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://crashcourse.ca
========================================================================
On Sun, Dec 23, 2007 at 06:13:03AM -0500, 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.
Jeff, very good! I like it. Thank you! ;-)
>
>Merry Christmas and Happy Holidays to all!
>
Merry Christmas, kernel hackers!
Best wishes!
Robert P. J. Day schrieb:
> 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.
>
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
On Sun, 23 Dec 2007, Dieter Ries wrote:
> Robert P. J. Day schrieb:
> > 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
========================================================================
Dieter Ries wrote:
> 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/
On Sun, Dec 23, 2007 at 06:13:03AM -0500, Jeff Garzik <[email protected]> wrote:
> 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
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
========================================================================
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.
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.
--
Stefan Richter
-=====-=-=== ==-- =====
http://arcgraph.de/sr/
Stefan Richter <[email protected]> writes:
> 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.
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
>>
>
> 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
Stefan Richter wrote:
> 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
Jeff Garzik wrote:
> 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/
Hi,
Le lundi 30 juin 2008, Jeff Garzik a ?crit :
> 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.