[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090115094938.GB5833@elte.hu>
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