[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.1.10.0805010812360.5623@fbirervta.pbzchgretzou.qr>
Date: Thu, 1 May 2008 08:15:18 +0200 (CEST)
From: Jan Engelhardt <jengelh@...ozas.de>
To: Andrew Morton <akpm@...ux-foundation.org>
cc: Dmitri Vorobiev <dmitri.vorobiev@...il.com>,
torvalds@...ux-foundation.org, rjw@...k.pl, davem@...emloft.net,
linux-kernel@...r.kernel.org, jirislaby@...il.com, mingo@...e.hu
Subject: Re: Slow DOWN, please!!!
On Thursday 2008-05-01 00:10, Andrew Morton wrote:
>>
>> Andrew, the latter thing is a very good point. For me personally, the fact
>> that -mm is not available via git is the major obstacle for trying your
>> tree more frequently than just a few times per year.
>
>Every -mm release if available via git://, as described in the release
>announcements.
[...]
>> How difficult it
>> would be to switch to git for you?
>
>Fatal, I expect. A tool which manages source-code files is just the wrong
>paradigm. I manage _changes_ against someone else's source files.
Would you mind using stgit? That you way have the queue patch
functionality, yet a simple git-push -f will send the whole
patch stack over to a repo (without the stgit bits that is),
leaving what looks like a regular tree with just lots of
recent commits. Does not even need extra scripts to do a
patchset->git conversion.
>> For busy (or lazy) people like myself, the big problem with linux-next are
>> the frequent merge breakages, when pulling the tree stops with "you are in
>> the middle of a merge conflict".
>
>Really? Doesn't Stephen handle all those problems? It should be a clean
>fetch each time?
Indeed, assuming the remote is set up and you have a local branch,
`git reset --hard mm/master` after a fetch is the thing.
But be sure not to have any changed files.
--
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