On Tue, 15 Jul 2008 08:57:41 +0200 Stefan Schmidt <[EMAIL PROTECTED]> wrote:
> Hello. > > On Mon, 2008-07-14 at 18:25, Antonio Ospite wrote: > > > Now that we are in the process of preparing our patches for mainline > > submission, using git could save us some time and headaches. > > Well, I'm thinking about this for three weeks now. It can also mean to switch > from one headache to another. ;) But let me explain a bit more. > > Our tools should help us to produce patches for the upstream kernel. It should > allow us to work on such a patch for a longer time. There are often many > commits > before we feel a patch is ready for review or submission. > > In quilt we handle this with a patchstack we go up and down. Making changes at > the right place of the stack, refresh and test it out. This way we always > have a > nice stack of separated patches we just need to prepare with headers and can > send away. > Yes, I see your point. having well separated patches is still needed before sending them for mainline inclusion but I am confident we will find a way to avoid to work with diff of diffs. > But there are also some con of quilt. We have to use svn as quilt has now > version control. The problem is here that we already have diffs and don't let > svn make the diffs between code, but patches. Looking at the commit mails > which > show me diffs of diffs makes them pretty hard to review for example. > The cons here are more about svn+quilt than quilt itself as you say. > So how we can use git for us? > About generating patches for submission: is there a way to generate a quilt patchset starting from a list of git commits? I haven't given a look to guilt and other suggested tools, so I don't know if that's what they do. About discussing changes and reviewing code: can we somehow replicate how things work in other trees? I mean, send a patch to openezx-devel for reviewing before committing to git.openezx.org. Yes, I know it may slow down the whole thing, I just want to hear your opinion about that. > To have different commits appear in one, needed if we want to send it upstream > as one patch, I see three different features which git offer us: > > git commit --amend > This allows you to easy make changes to the last commit. > > git add --interactive > Allows you to 'merge' some of your uncommited hunks into older commits > > git rebase --interactive > Allows you to change the history, squash commits together and more. > > To see if these features help us, we need to test them. So once the server is > running I would like to have a two weeks period to let people try out the new > workflow. > I agree, a testing period is needed, but let's keep it short to not stagnate too much. > That was long. Sorry. I just had thought about this for some time and liked to > share my thoughts. In short: Let's try it, but be carefull if it really helps > us. :) > ACK. Regards, Antonio -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Web site: http://www.studenti.unina.it/~ospite Public key: http://www.studenti.unina.it/~ospite/aopubkey.asc
pgp5v3a4TXBzM.pgp
Description: PGP signature
