linux-kernel - Re: Announce: Linux-next (Or Andrew's dream :-))

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:	Mon, 11 Feb 2008 22:07:26 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	greg@...ah.com
Cc:	arjan@...radead.org, sfr@...b.auug.org.au,
	linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
	linux-arch@...r.kernel.org, akpm@...ux-foundation.org,
	torvalds@...ux-foundation.org
Subject: Re: Announce: Linux-next (Or Andrew's dream :-))

From: Greg KH <greg@...ah.com>
Date: Mon, 11 Feb 2008 21:53:12 -0800

> Where do you "fix this up" at?  I can send a patch for the IB tree, but
> Roland can't put it in his tree, and I can't put it in my tree, it needs
> to go _after_ both of our trees.

Totally agreed.

The fact is there are interdependencies, especially in driver
land and you have to either:

1) Make the driver folks work on top of Greg's tree.

2) Constantly rebase the -next tree to deal with the
   conflicts.

There are some other issues related to this which haven't
be touched upon greatly yet.

I rebase my tree all the time, at least once or twice per
week.  Why?

Firstly, to remove crap.  When you have "great idea A" then "oh shit A
won't work, revert that" there is zero sense in keeping both
changesets around.

Secondly, I want to fix up the rejects caused by conflicts with
upstream bug fixes and the like (and there are tons when the tree gets
to 1500 or so patches like the networking did).  I don't want git to
merge the thing by hand, I want to see what the conflict is and make
sure the "obvious" resolution is OK and the most efficient way I know
how to do that is to suck my tree apart as patches, then suck them
back into a fresh tree.

It therefore might make sense to the linux-next tree to do something
similar, constantly rebasing so that all the conflicts and reverted
shit changes can be sorted out without having an incredibly ugly
GIT history.
--
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/