git guidance

Does somebody have a step by step tutorial for doing the standard "edit - test - modify - retest - submit - edit - resubmit" sequence with GIT? Is there a GIT newsgroup or mailinglist? Or should I just post my silly questions to LKML?

So I've watched Linus' Google Tech Talk about git and let him convince me that I've been stupid to use CVS, that Subversion is even worse, and the only sensible approach is to use git. Went ahead and tried to convert my driver development to git.

It didn't work too well. The first result was one of maximal
embarrassment: I produced a patch that didn't even compile when applied to the official tree. This shouldn't happen with git, right? Well, it did. So now I'm back to keeping a virgin kernel source tree alongside my development area in order to produce diffs. That can't be right?

Obviously I'm still being stupid. (Probably an aftereffect of using CVS for too long.) But where do I turn for guidance? I read all the docs and READMEs I could find, but I still don't understand why GIT doesn't produce the results I need, and what to do differently.

Does somebody have a step by step tutorial for doing the standard "edit - test - modify - retest - submit - edit - resubmit" sequence with GIT? Is there a GIT newsgroup or mailinglist? Or should I just post my silly questions to LKML?

TIA

Signature · 4 lines

Tilman Schmidt                          E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)

It didn't work too well. The first result was one of maximal
embarrassment: I produced a patch that didn't even compile when applied to the official tree. This shouldn't happen with git, right? Well, it did. So now I'm back to keeping a virgin kernel source tree alongside my development area in order to produce diffs. That can't be right?

Does somebody have a step by step tutorial for doing the standard "edit - test - modify - retest - submit - edit - resubmit" sequence with GIT? Is there a GIT newsgroup or mailinglist? Or should I just post my silly questions to LKML?

Greetings,

Google is your friend. If you're looking for irc channels you can always try #git at irc.freenode.net Git howto/tutorial/... doesn't belong in the kernel mailinglist.

Quoted 4 lines · Kristoffer Ericson

Greetings,

Google is your friend. If you're looking for irc channels you can always try #git at irc.freenode.net Git howto/tutorial/... doesn't belong in the kernel mailinglist.

Well, I don't agree with you. His question is about how to use GIT to develop his driver.
1) linux-kernel is a development ML.
2) he needs help from people how already encountered such beginner's issues and who might git very good advices.

It should not turn into an endless thread led by people who want to redefine GIT's roadmap, but experience sharing helps a lot with GIT.

Tilman, there was a howto by Jeff Garzik I believe. It helped me a lot when I didn't understand a damn command, even if it was in the very old ages (version 0.5 or something like this). The tutorials on the GIT site are quite good too. You must read them entirely and proceed with the examples as you read them. Believe me, it helps you understand a lot of things, specially about the split in 3 parts (objects, cache, and working dir).

I really think that if your patches do not apply, it's because you have lost some changes due to a wrong initial use possibly caused by a mis-understanding of the tool. It happened to me too, but in this case you can almost certainly find your old changes in older commits.

I really hope that soon someone will come up with a big 400-pages book called "GIT" with a lot of good advices. It would be awesome.

Anyway, don't get demotivated about the tool or the workflow. If you find it inconvenient to use, you're doing something wrong and you don't know it.

Regards,
Willy

Tilman, there was a howto by Jeff Garzik I believe. It helped me a lot when I didn't understand a damn command, even if it was in the very old ages (version 0.5 or something like this). The tutorials on the GIT site are quite good too. You must read them entirely and proceed with the examples as you read them. Believe me, it helps you understand a lot of things, specially about the split in 3 parts (objects, cache, and working dir).

So I've watched Linus' Google Tech Talk about git and let him convince me that I've been stupid to use CVS, that Subversion is even worse, and the only sensible approach is to use git. Went ahead and tried to convert my driver development to git.

TIA

Google is your friend.

Quoted 1 line · Kristoffer Ericson

Google is your friend.

Sigh.

In case you didn't guess, I *have* of course searched Google, and not just that. I thought the wording of my request would have made that sufficiently clear. Do I really have to add the phrase "Yes, I have searched Google!" to my sig?

Signature · 3 lines

Tilman Schmidt                    E-Mail: [email protected]
Bonn, Germany
Yes, I have searched Google!

It should not turn into an endless thread led by people who want to redefine GIT's roadmap, but experience sharing helps a lot with GIT.

Tilman, there was a howto by Jeff Garzik I believe.

The tutorials
on the GIT site are quite good too. You must read them entirely and proceed with the examples as you read them. Believe me, it helps you understand a lot of things, specially about the split in 3 parts (objects, cache, and working dir).

Anyway, don't get demotivated about the tool or the workflow. If you find it inconvenient to use, you're doing something wrong and you don't know it.

Quoted 2 lines · Willy Tarreau

It should not turn into an endless thread led by people who want to redefine GIT's roadmap, but experience sharing helps a lot with GIT.

Well, now that you mentioned it, if there is one thing I dislike, it's for version control to start mutilating your sources. Version Control should be completely transparent. GIT isn't.

Thanks!

--
Al

Quoted 8 lines · Tilman Schmidt

It didn't work too well. The first result was one of maximal
embarrassment: I produced a patch that didn't even compile when applied to the official tree. This shouldn't happen with git, right? Well, it did. So now I'm back to keeping a virgin kernel source tree alongside my development area in order to produce diffs. That can't be right?

No, it can't. Use stgit/quilt ;p

Quoted 5 lines

Does somebody have a step by step tutorial for doing the standard "edit - test - modify - retest - submit - edit - resubmit" sequence with GIT? Is there a GIT newsgroup or mailinglist? Or should I just post my silly questions to LKML?

http://www.linuxworld.com/video/?bcpid=1138309735&bclid=1213841149&bctid=1221911905

James Bottomley's intro helps a lot.
-
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/

There is a project listed on the kernel.org git page called guilt. I find it very useful. It is much more responsive than stgit and it actually has a git backend which quilt does not.

Quoted 7 lines · Jan Engelhardt

Quoted 5 lines · Tilman Schmidt

Well, it did. So now I'm back to keeping a virgin kernel source tree alongside my development area in order to produce diffs. That can't be right?

No, it can't. Use stgit/quilt ;p

Quoted 11 lines · Dave Quigley

There is a project listed on the kernel.org git page called guilt. I find it very useful. It is much more responsive than stgit and it actually has a git backend which quilt does not.

Quoted 6 lines · Jan Engelhardt

Quoted 5 lines · Tilman Schmidt

Well, it did. So now I'm back to keeping a virgin kernel source tree alongside my development area in order to produce diffs. That can't be right?

Quoted 1 line

Quoted 1 line

No, it can't. Use stgit/quilt ;p

In which respect would stgit/quilt/guilt help me? At first glance they just seem to add another level of complexity.

Thanks,
Tilman

Hi,

Quoted 9 lines

Quoted 7 lines · Al Boldi

Quoted 2 lines · Willy Tarreau

It should not turn into an endless thread led by people who want to redefine GIT's roadmap, but experience sharing helps a lot with GIT.

Well, now that you mentioned it, if there is one thing I dislike, it's for version control to start mutilating your sources. Version Control should be completely transparent. GIT isn't.

Quoted 3 lines

Care to explain? Git is quite happy handling arbitrary binary content, so I find it difficult to believe that it is changing your source code in strange ways.

It is nice of you to ask him to explain: Unless this handwaving claim is substantiated, it is quite hard to argue with.

git@vger sometimes bounces, so let's leave lkml as backup.

Quoted 15 lines · Johannes Schindelin

Quoted 13 lines · Rogan Dawes

Quoted 8 lines · Al Boldi

Quoted 3 lines · Willy Tarreau

It should not turn into an endless thread led by people who want to redefine GIT's roadmap, but experience sharing helps a lot with GIT.

Well, now that you mentioned it, if there is one thing I dislike, it's for version control to start mutilating your sources. Version Control should be completely transparent. GIT isn't.

Care to explain? Git is quite happy handling arbitrary binary content, so I find it difficult to believe that it is changing your source code in strange ways.

Quoted 2 lines

It is nice of you to ask him to explain: Unless this handwaving claim is substantiated, it is quite hard to argue with.

Sure, the problem with GIT is that it stores the sources inside a backend container that is only accessible via GIT; iow, you can't retrieve your sources directly / transparently.

By that definition, no SCM, not even CVS, is transparent. Nothing short of unpacked directories of all versions (wasting a lot of disk space) would.

Quoted 3 lines · Johannes Schindelin

By that definition, no SCM, not even CVS, is transparent. Nothing short of unpacked directories of all versions (wasting a lot of disk space) would.

Who said anything about unpacking?

I'm talking about GIT transparently serving a Virtual Version Control dir to be mounted on the client.

Quoted 78 lines · Dave Quigley

Quoted 15 lines · Tilman Schmidt

Quoted 13 lines · Dave Quigley

There is a project listed on the kernel.org git page called guilt. I find it very useful. It is much more responsive than stgit and it actually has a git backend which quilt does not.

Quoted 7 lines · Jan Engelhardt

Quoted 5 lines · Tilman Schmidt

Well, it did. So now I'm back to keeping a virgin kernel source tree alongside my development area in order to produce diffs. That can't be right?

Quoted 9 lines

Quoted 2 lines

Quoted 2 lines

No, it can't. Use stgit/quilt ;p

In which respect would stgit/quilt/guilt help me? At first glance they just seem to add another level of complexity.

Thanks,
Tilman

These tools allow you to maintain a set of patches with very little effort. More importantly it removes a lot of the git specifics from your development process. For example this is how I use guilt for a new patch set.

I take my fresh tree and do a guilt-init in the base. This will create a new patch series. I then need to create a patch to modify something LSM related (guilt-new <patch_name>). Things like stgit/quilt/git use the idea of a stack of patches. At this point if you were to type guilt-series you would only see the one patch we just created. This patch is going to be one logical set of changes (it should also produce a compilable and working kernel). You can make whatever modifications you need to make to your files and at this point you need to do one of two things. If they were already in the tree you just type guilt-refresh and under your .git/patches/<branch_name> directory you will see a file named <patch_name> which contains your patch. Otherwise you need to do a guilt-add <file_name> and then a guilt-refresh. The idea here is that you have a moved your workflow from managing a series of commits and then breaking out patches from a final version to one where you think in terms of the patches and make modifications to them instead. In my example I said I was doing something LSM related. Lets say the first patch added a new hook and its implementation in the various modules. We can now add a second patch using the guilt-new command and this one will add uses of that new hook. At this point we have a stack that looks like this.

<patch that adds users>
<patch that adds hook>

I can pop and push patches onto this stack to have a version of my kernel tree at any state within the patch set. At this point lets say we have posted the patch set and have feedback. I need to apply this feedback to the patch that adds the LSM hook. Since my top patch (guilt-top) is currently at the one that adds the users of the hook I need to pop off that patch and get to the one that creates the hook (guilt-pop). After doing this I'm at a kernel tree state which just has the changes which add the hook. I make my modifications, type guilt-refresh to create a new patch and then guilt-push my second patch on and make sure everything is still working.

As you can see there is almost no git knowledge required to use this system and it allows you to focus on development instead of the versioning system. One useful feature is that when Linus adds new patches and I want to rebase my set against the current tree It only takes 3 commands to rebase the patch set (Assuming all goes well).

guilt-push -a #push all patches onto the stack git-fetch #pull down the index
guilt-rebase FETCH_HEAD #Rebase our patches should do a merge and #reapply all patches

Quoted 6 lines

These are just some basics about guilt. Jeff has written a better tutorial with a sample repository for you to work with if your interested. I don't know if this will help your development process but I can tell you from experience breaking patches by hand was a pain in the ass and a huge waste of time and I'm glad to have a tool like this

Where can I find that tutorial ?

regards

Quoted 9 lines

now.

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

Quoted 15 lines · Tilman Schmidt

Quoted 13 lines · Dave Quigley

There is a project listed on the kernel.org git page called guilt. I find it very useful. It is much more responsive than stgit and it actually has a git backend which quilt does not.

Quoted 7 lines · Jan Engelhardt

Quoted 5 lines · Tilman Schmidt

Well, it did. So now I'm back to keeping a virgin kernel source tree alongside my development area in order to produce diffs. That can't be right?

Quoted 9 lines

Quoted 2 lines

Quoted 2 lines

No, it can't. Use stgit/quilt ;p

In which respect would stgit/quilt/guilt help me? At first glance they just seem to add another level of complexity.

Thanks,
Tilman

These tools allow you to maintain a set of patches with very little effort. More importantly it removes a lot of the git specifics from your development process. For example this is how I use guilt for a new patch set.

I take my fresh tree and do a guilt-init in the base. This will create a new patch series. I then need to create a patch to modify something LSM related (guilt-new <patch_name>). Things like stgit/quilt/git use the idea of a stack of patches. At this point if you were to type guilt-series you would only see the one patch we just created. This patch is going to be one logical set of changes (it should also produce a compilable and working kernel). You can make whatever modifications you need to make to your files and at this point you need to do one of two things. If they were already in the tree you just type guilt-refresh and under your .git/patches/<branch_name> directory you will see a file named <patch_name> which contains your patch. Otherwise you need to do a guilt-add <file_name> and then a guilt-refresh. The idea here is that you have a moved your workflow from managing a series of commits and then breaking out patches from a final version to one where you think in terms of the patches and make modifications to them instead. In my example I said I was doing something LSM related. Lets say the first patch added a new hook and its implementation in the various modules. We can now add a second patch using the guilt-new command and this one will add uses of that new hook. At this point we have a stack that looks like this.

<patch that adds users>
<patch that adds hook>

I can pop and push patches onto this stack to have a version of my kernel tree at any state within the patch set. At this point lets say we have posted the patch set and have feedback. I need to apply this feedback to the patch that adds the LSM hook. Since my top patch (guilt-top) is currently at the one that adds the users of the hook I need to pop off that patch and get to the one that creates the hook (guilt-pop). After doing this I'm at a kernel tree state which just has the changes which add the hook. I make my modifications, type guilt-refresh to create a new patch and then guilt-push my second patch on and make sure everything is still working.

As you can see there is almost no git knowledge required to use this system and it allows you to focus on development instead of the versioning system. One useful feature is that when Linus adds new patches and I want to rebase my set against the current tree It only takes 3 commands to rebase the patch set (Assuming all goes well).

guilt-push -a #push all patches onto the stack git-fetch #pull down the index
guilt-rebase FETCH_HEAD #Rebase our patches should do a merge and #reapply all patches

These are just some basics about guilt. Jeff has written a better tutorial with a sample repository for you to work with if your interested. I don't know if this will help your development process but I can tell you from experience breaking patches by hand was a pain in the ass and a huge waste of time and I'm glad to have a tool like this

now.

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

Willy,

thanks for your kind answer.

Quoted 1 line · Willy Tarreau

Tilman, there was a howto by Jeff Garzik I believe.

Yes, I started from that and it's fine as far as it goes. The "Everyday GIT With 20 Commands Or So" document was quite helpful too, especially the section "Individual Developer (Participant)". But they don't quite cover my workflow yet.

Quoted 5 lines

The tutorials
on the GIT site are quite good too. You must read them entirely and proceed with the examples as you read them. Believe me, it helps you understand a lot of things, specially about the split in 3 parts (objects, cache, and working dir).

I think I got that part. My questions concern practical things like when to make a new branch, how to resubmit a patch following post-commit changes, what to do when "git format-patch" doesn't produce the desired result

or when "git pull" obstinately declares "Already up-to-date" even though I know that isn't true,

how to
track a patch after submission to LKML to see when or whether it appears in the main tree, or how to scrub the history to stop "git log origin..HEAD" from listing (and "git format-patch" from formatting) long-merged changes as new. Well, I'll take that up on the [email protected] list then, as proposed by J. Bruce Fields, in order not to annoy LKML readers any longer.

Quoted 3 lines

Anyway, don't get demotivated about the tool or the workflow. If you find it inconvenient to use, you're doing something wrong and you don't know it.

That's what I'm thinking. What I'm trying to do can't be that different from what all those happy git users are doing. I guess if I could just watch an experienced git user at work for a day most of my problems would vanish.

Quoted 8 lines · Tilman Schmidt

It didn't work too well. The first result was one of maximal
embarrassment: I produced a patch that didn't even compile when applied to the official tree. This shouldn't happen with git, right? Well, it did. So now I'm back to keeping a virgin kernel source tree alongside my development area in order to produce diffs. That can't be right?

No, it can't. Use stgit/quilt ;p

Quoted 5 lines · Al Boldi

Quoted 3 lines · Johannes Schindelin

By that definition, no SCM, not even CVS, is transparent. Nothing short of unpacked directories of all versions (wasting a lot of disk space) would.

Quoted 4 lines

Who said anything about unpacking?

I'm talking about GIT transparently serving a Virtual Version Control dir to be mounted on the client.

Are you talking about something like (in alpha IIRC) gitfs?

http://www.sfgoth.com/~mitch/linux/gitfs/

Besides, you can always use "git show <revision>:<file>". For example gitweb (and I think other web interfaces) can show any version of a file or a directory, accessing only repository.

No, use "git rebase --interactive" ;-)

You should watch this one http://youtube.com/watch?v=8dhZ9BXQgc4 . It's better 8-)

Quoted 1 line · Jakub Narebski

Besides, you can always use "git show <revision>:<file>". For example gitweb (and I think other web interfaces) can show any version of a file or a directory, accessing only repository.

Sure, browsing is the easy part, but Version Control starts when things become writable.

Quoted 2 lines · Haavard Skinnemoen

No, use "git rebase --interactive" ;-)

What's that? I can't find it in "man git-rebase".

Quoted 5 lines · Al Boldi

Quoted 2 lines · Willy Tarreau

It should not turn into an endless thread led by people who want to redefine GIT's roadmap, but experience sharing helps a lot with GIT.

Quoted 3 lines

Well, now that you mentioned it, if there is one thing I dislike, it's for version control to start mutilating your sources. Version Control should be completely transparent. GIT isn't.

Care to explain? Git is quite happy handling arbitrary binary content, so I find it difficult to believe that it is changing your source code in strange ways.