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

Powered by Openwall GNU/*/Linux Powered by OpenVZ