Date:	Thu, 15 Jan 2009 10:49:38 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Mike Travis <travis@....com>
Cc:	Yinghai Lu <yinghai@...nel.org>, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] x86: arch_probe_nr_irqs


* Mike Travis <travis@....com> wrote:

> Very cool, thanks!!
> 
> The one thing I always get hung up on is what args to use with the git 
> rebase -i command.  Say I want to edit 4a046d1 (which I do ;-), I see it 
> in my repo with git-log (3rd one down):

You shouldnt edit 4a046d1 anymore as i already pulled it - you can queue 
up a fix commit. (Or we can decide to drop the whole tree and re-pull 
yours - but that is an emergency path not to be taken lightly.)

Btw., to 'edit' your own commits, you can always do something like this. 
For example, if this is the current lineup of your own commits (not yet 
pulled by anyone):

 a4a0acf: x86: fix broken flush_tlb_others_ipi()
 28e0886: xen: fix too early kmalloc call
 92296c6: cpumask, irq: non-x86 build failures
 542d865: kstat: modify kstat_irqs_legacy to be variable sized
 9332fcc: irq: initialize nr_irqs based on nr_cpu_ids
 0fa0ebb: irq: allocate irq_desc_ptrs array based on nr_irqs
 e2f4d06: irq: use WARN() instead of WARN_ON().

... and you realize that there's a bug in the middle, at 542d865, that 
you'd like to fix locally before pushing it out for others to pull.

In this case you can rebase and fix in "two phases". The first phase is to 
'reorder commits':

  git rebase -i 542d865^1

i.e. you start your rebase _from before_ the commit in question. All old 
history will be preserved (which is always good - you always want the 
minimum rebase - avoid full rebases as much as possible).

You will be offered this git-rebase screen:

 pick 542d865 kstat: modify kstat_irqs_legacy to be variable sized
 pick 92296c6 cpumask, irq: non-x86 build failures
 pick 28e0886 xen: fix too early kmalloc call
 pick a4a0acf x86: fix broken flush_tlb_others_ipi()

Edit it to move the first line to the last, like this:

 pick 92296c6 cpumask, irq: non-x86 build failures
 pick 28e0886 xen: fix too early kmalloc call
 pick a4a0acf x86: fix broken flush_tlb_others_ipi()
 pick 542d865 kstat: modify kstat_irqs_legacy to be variable sized

and run the rebase. Now you'll have a new lineup with the buggy commit at 
the end. (lets assume there were no conflicts caused by the reordering) 
For example you could get:

 b304542: kstat: modify kstat_irqs_legacy to be variable sized
 d398631: x86: fix broken flush_tlb_others_ipi()
 ab6211f: xen: fix too early kmalloc call
 ef3b48b: cpumask, irq: non-x86 build failures
 9332fcc: irq: initialize nr_irqs based on nr_cpu_ids
 0fa0ebb: irq: allocate irq_desc_ptrs array based on nr_irqs
 e2f4d06: irq: use WARN() instead of WARN_ON().

note how there's new commit IDs starting at ef3b48b - but all previous 
commits (9332fcc, 0fa0ebb, e2f4d06) were preserved.

Now comes 'phase 2': the problematic commit is at the end of the lineup 
and you can fix it in multiple development steps, by editing the buggy 
source and adding it to the commit via:

   git add kernel/file.c
   git commit --amend

Ok?

( Or if you are sure you can fix the bug via a single pass, you can change 
  the 'pick' line to 'edit' and do the editing and 'git commit --amend' 
  right during the rebase. If it's still not perfect it needs another 
  rebase though and it's easy to mess up rebases. )

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists