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:	Tue, 12 Feb 2008 20:03:54 +0000
From:	Russell King <rmk+lkml@....linux.org.uk>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Jeff Garzik <jeff@...zik.org>, David Miller <davem@...emloft.net>,
	arjan@...radead.org, greg@...ah.com, sfr@...b.auug.org.au,
	linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
	linux-arch@...r.kernel.org, akpm@...ux-foundation.org
Subject: Re: Announce: Linux-next (Or Andrew's dream :-))

On Tue, Feb 12, 2008 at 09:09:34AM -0800, Linus Torvalds wrote:
> I also don't think rebasing helps the particular problem under discussion 
> (ie conflicts due to having to sort out dependencies between different 
> trees), and in some ways hurts it.

How do you suggest that we fix the problems we had with the initial
merge with the ARM tree.

We were in the situation where, had I asked you to pull my tree, you'd
have had a fair number of conflicts to resolve - I tested this by trying
to merge your tree into my 'devel' head.

The result wasn't pleasant - even I didn't know how to fix up a lot of
those conflicts, so the only way I could move forward was to reconstruct
the 'devel' head (which is just merges of other branches) omitting the
problem branches.

This then posed something of a problem - of which I saw three solutions:

1. ask the original authors of changes in those problem branches to come
   up with patches or fixes in their git trees (in the rare case that
   they have git trees) to bring the branch into line with the conflicting
   changes in mainline.  The resulting branch with that change applied
   probably won't build, which means bisect pain for people who happen
   to bisect to that point.

2. botch the merge, publish the tree, and then hit heads together to try
   and get the problem resolved - again resulting in a commit point (the
   merge) which is nonsense and unbuildable.

3. rebase the branch on top of the conflicting change, throw out the
   patches which prove to be a problem and ask the original author of
   those patches to fix them up for the conflicting change.  The result
   is a completely bisectable tree.

(3) is the solution which I chose, and it worked _extremely_ well.

(3) is effectively what akpm does with his tree - when a patch conflicts
with other changes, he throws the changes out and bangs peoples heads
together to get a new set of patches generated which work together.  In
that respect, it's no different, and it's been proven there to work well.
So I see git as being no different.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
--
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/