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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 12 Feb 2008 11:03:39 -0600
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	Jeff Garzik <jeff@...zik.org>
Cc:	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, torvalds@...ux-foundation.org
Subject: Re: Announce: Linux-next (Or Andrew's dream :-))

On Tue, 2008-02-12 at 11:36 -0500, Jeff Garzik wrote:
> David Miller wrote:
> > This is why, with the networking, we've just tossed all of the network
> > driver stuff in there too.  I can rebase freely, remove changesets,
> > rework them, etc. and this causes a very low amount of pain for Jeff
> > Garzik and John Linville.
> 
> 
> s/very low/not low/
> 
> Rebasing is always a pain, and John and I both agreed the other day that 
> you do it too often.
> 
> I've complained about this before, too...  but figured this was just 
> another thing I was getting ignored on, and so life moved on.  But don't 
> try to sell rebasing as "low pain".
> 
> Rebasing makes the history all nice and pretty, but by totalling 
> flattening the history, trashing all the commit ids (and rewriting 
> associated metadata), you create obvious downstream problems.
> 
> Rebasing is  low impact only if you don't have git downstream people. 
> Otherwise, you're just treating it as a useful quilt clone, really.

I used to be in this camp too: seeing rebasing as the ultimate evil.
However, what I found was that as I tried to preserve my merge tree's
history, I was picking up merge points with non trivial fixups.  You can
argue that this is how git is supposed to operate, but the problem is
that these merge points become immovable objects in the tree history ...
I can't rebase the tree at all any more and I can't simply remove a
commit (which gets messy for commits duplicated by other trees)  They
also effectively separate the fix up from the patch causing it.   Plus,
it became difficult for people to go to gitweb to see the tree history,
because everything before the merge point got buried.

I finally concluded that I needed to rebase my trees to resolve
conflicts rather than merging them.  The advantages are I know the exact
patch with the problem and I can keep the history annotated with what
had to be done to get it to apply.  Plus with git (and this is a huge
advantage over quilt) knowing the base of the patch, I can still use the
merge algorithms to help me do the fixup.

I'm not saying rebase constantly ... I'm still mindful of the disruption
it causes, so I only do it if I pick up an actual conflict.  However, I
do think it does becomes necessary at times.

The problem rebasing causes is that git is pretty horrible at rebasing a
tree which is based on your now rebased tree (try saying that after a
few martinis).  Git really needs to acquire better rebasing tools for
this one case, but if that were solved, I think a lot of the objections
to rebasing could be answered.

James

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