linux-kernel - Re: [PATCH 1/6] sched: Fix (harmless) typo 'CONFG_FAIR_GROUP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Jul 2011 01:03:31 +0200 (CEST)
From:	Jesper Juhl <jj@...osbits.net>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Jiri Kosina <jkosina@...e.cz>,
	Jan H. Schönherr <schnhrr@...tu-berlin.de>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/6] sched: Fix (harmless) typo
 'CONFG_FAIR_GROUP_SCHED'

On Thu, 14 Jul 2011, Peter Zijlstra wrote:

> On Thu, 2011-07-14 at 00:35 +0200, Jesper Juhl wrote:
> > 
> > Don't know your workflow, but I can tell you what I do. I just have a 
> > branch for patches that I'm gathering that are not yet in upstream. Apply 
> > any new stuff there (or cherry-pick from other branches to my queue 
> > branch) and then regularly rebase that branch on master (Linus' tree).
> > When I then want to resend some patches it's as simple as checking out my 
> > queue branch, doing a rebase to make sure there's no obsolete stuff in it 
> > and then  git format-patch  to generate mails for the patches I want to 
> > re-send and then read those patches in to re-alpine and send them.
> > To me that's not very painfull, but of course it may not match your 
> > workflow - just a description of mine :-) . 
> 
> Right, so I find cherry-picking and rebasing using git the most painful
> thing ever.
> 
> Also, using quilt you get a plain text version of the patch you can edit
> at your leisure, editing a git patch involves some export, import and
> rebase foo which is all too much work.
> 

Hmm, if I want to modify a patch in my queue I'll do something like this:

$ git checkout queue

$ git rebase --interactive HEAD~5  (or however long I need to go back)

## change the 'pick' for the patch I want to change to 'edit' in the list 
## that pops up in my editor.

## edit the files I need to edit

$ git add <modified files>

$ git commit --amend

## update patch description (if needed)

$ git rebase --continue

<done>

perhaps that seems too much work to you - for me it works just fine..


> Furthermore, using quilt I get help from useful tools like rej and meld
> git-merge otoh creates these god-awful merge markers that no tool can
> deal with.
> 
don't use those tools, so can't really comment.

> As for re-alpine, I might actually try it, you're the second one
> promoting it. Although I had somewhat hoped for a MUA like sup to become
> useful (or notmuch to grow a usable front-end). Traditional MUAs simply
> can't seem to cope well with today's number of emails.

Do yourself a favour, if you try it, and spend a bit of time in the Setup 
menu configuring it to the threading style you want, the headers you want 
displayed by default, etc etc... The defaults are less than perfect if you 
ask me, but it's quite configurable :)

-- 
Jesper Juhl <jj@...osbits.net>       http://www.chaosbits.net/
Don't top-post http://www.catb.org/jargon/html/T/top-post.html
Plain text mails only, please.

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