Messages in this thread | | | Date | Thu, 15 Jan 2009 10:49:38 +0100 | From | Ingo Molnar <> | Subject | Re: [PATCH] x86: arch_probe_nr_irqs |
| |
* Mike Travis <travis@sgi.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
| |