linux-kernel - Re: [alsa-devel] HG -> GIT migration

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:	Wed, 21 May 2008 16:47:04 +0200
From:	Takashi Iwai <tiwai@...e.de>
To:	Rene Herman <rene.herman@...access.nl>
Cc:	alsa-devel@...a-project.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [alsa-devel] HG -> GIT migration

At Wed, 21 May 2008 15:04:53 +0200,
Rene Herman wrote:
> 
> On 21-05-08 14:37, Takashi Iwai wrote:
> 
> > At Wed, 21 May 2008 14:30:31 +0200,
> > Rene Herman wrote:
> 
> >> $ git remote show sound-2.6
> >> * remote sound-2.6
> >>    URL: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git
> >>    Tracked remote branches
> >>      master
> >>
> >> What's the status of that one now? Should I continue pulling that one or 
> >> should I switch to the new alsa-kernel GIT repo? I want to pull it into 
> >> a Linus clone tree...
> > 
> > We are working on this right now.  alsa.git is far currently behind my
> > tree.
> > 
> > One problem we hit is about multiple committers and rebase.  If you do
> > git-rebase, the commiter information is touched although the sign-off
> > isn't updated.  git-rebase looks apparently designed for the
> > single-commiter model.
> 
> It's "worse" than that; rebasing is designed for a _private_ development 
> model. git-rebase is a very handy tool for people like myself (people 
> without a downstream that is) and it basically enables the quilt model 
> of a stack of patches on top of git but public trees that have people 
> pulling from them should generally not rebase or everyone who _is_ 
> pulling finds a different tree each time.
> 
> Linus is vehement about this also. There have a few threads about it and 
> the most recent was:
> 
> http://lkml.org/lkml/2008/5/17/190
> 
> I'm also not an experienced git user (not other than in my own leafnode 
> developer mode, certainly) but I expect Linus might not terribly mind 
> answering a few questions about the model -- ALSA is a significant 
> subsystem and it switching to GIT might even make for a nice "this is 
> how you do that as a subsystem" treatise...
> 
> (ie, also added linux-kernel)

Theoretically we can work only using merges.  However, the resultant
tree will look too complex with lots of merge points at the time of
the next merge window.  This is also a nightmare for bisecting.  Thus,
most subsystem trees do rebase before the merge window in practice,
AFAIK.

It'd be appreciated if someone can tell me any good workflow to keep a
good-shaped tree without rebasing...


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