From owner-freebsd-hackers@FreeBSD.ORG Sun Sep 18 22:51:23 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C823106566B; Sun, 18 Sep 2011 22:51:23 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8613A8FC08; Sun, 18 Sep 2011 22:51:22 +0000 (UTC) Received: by fxg9 with SMTP id 9so4561060fxg.13 for ; Sun, 18 Sep 2011 15:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=9PIc4on4son74HIwbe+9jQrxqMxAd5bn1Q/GGxihNCg=; b=leAK2sQ7GnLRAHP59cIKP5HQNvxWI9DiR4iGCvsrcJQqF8ilCat8pvSDaGuJYHzjuJ ZciuNj4DypO24fj/8vAYh+N6LpdT1/pB1WfemIZOb/HNghj96alz0wpVIuLig7wducgK aJrSIhCNz36s2eo8fiA+Pluz/NLXl01DvCtro= Received: by 10.223.89.65 with SMTP id d1mr3961785fam.6.1316384813412; Sun, 18 Sep 2011 15:26:53 -0700 (PDT) Received: from localhost ([78.157.92.5]) by mx.google.com with ESMTPS id b10sm19736977fam.1.2011.09.18.15.26.51 (version=SSLv3 cipher=OTHER); Sun, 18 Sep 2011 15:26:52 -0700 (PDT) Date: Mon, 19 Sep 2011 01:25:41 +0300 From: Gleb Kurtsou To: Andriy Gapon Message-ID: <20110918222541.GA86842@tops> References: <4E712D11.7040202@FreeBSD.org> <4E75B67E.1000802@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4E75B67E.1000802@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hackers@FreeBSD.org Subject: Re: Fwd: my git development snapshot(s) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Sep 2011 22:51:23 -0000 On (18/09/2011 12:14), Andriy Gapon wrote: > > Just decided to follow the global trends and trying to throw all of my > local/private changes at you in hope that the "crowd-sourcing magic" might > somehow happen :-) This seems definitely easier than carefully producing the > patch files and keeping them up-to-date. > > So, my newly cloned gitorious repository: > https://gitorious.org/~avg/freebsd/avgbsd > > And the first branch of interest: > https://gitorious.org/~avg/freebsd/avgbsd/commits/devel-20110915 > > This is a snapshot of almost all of my local changes to the FreeBSD src tree. > Please note that the branch is not intended to be public in the git sense. That > is, there will be no linear history - I periodically rebase my changes on top of > the svn head and also frequently reshuffle/merge/split commits. > The snapshot is not tidied up, there are quite a few commits that should be > merged into other commits, some commit messages are not accurate/pretty, etc. > The older the commits, the more mature they are supposed to be. > > Based on the above, no new commits are expected to this snapshot branch. > I will produce new snapshot branches from time to time. > > I am posting this information to this list initially, later I plan to share the > code with the wider audience e.g. via hackers@. > > P.S. This code sharing is made easier for me by git, Gitorious and "git rebase > --onto" in particular. Thanks to Fabien Thomas for the initial FreeBSD clone > repository at Gitorious! Let me share my experience as well. My repo: https://github.com/glk/freebsd-head/ I used rebase to keep local branches as well, but no longer do so. Such setup worked for me at least for two years, I had local changes and worked on a larger patchset for 7,8-STABLE and CURRENT branches simultaneously (no longer do it either). But (imho) this approach his serious drawbacks. The biggest one is that it's hard to check if regression comes from your code or recently merged upstream code. The second one: once you screw rebase (merge) you are in big trouble. Both issues can be worked around by keeping previous master branches, but it hardly helps: once there are conflicts with upstream or your local changes get commited upstream it becomes only harder and harder. (I used to have master-prev-DATE similar to devel-DATE Andriy uses.) I like and use rebase a lot while working on the code: reorganize commits, small fixups, etc. But try not to touch code that is more than several days old unless really necessary. The reason is to maintain code base in well tested state: imagine you've changed or small bit in HEAD~20, a week later you find a bug, bisect to find that it showed up in orig-HEAD~10 because of your small fix in orig-HEAD~20. Fixing it would have taken less time without that rebase, or bug wouldn't appear in the first place. Once history stabilizes (i.e. remains untouched for 3-4 days) I push it public or backup (for local projects) repository. There is no history rewriting after this point. Use separate branches for independent patchsets. E.g. tmpfs branch - for tmpfs changes, misc - for smaller changes, etc. It lets me bisect and test code easier. For example if I get strange panic I could create temporal branch with all patchsets except pefs branch. Test it, find faulty branch, bisect individual changes. Besides it's also possible to bisect master branch, merge appropriate patchset revisions while bisecting upstream, etc. Upgrade procedure. Patchset branches are independently merged with upstream (vendor/master in my case). And all patchset branches are merged into master branch. In other words resolve conflicts in patchset branches, merge everything back to master. I usually merge individual branches only if there are conflicts or after important milestone. Octopus merge in git may not be as good as you I'd like it to if there are conflicts in several branches, but it's manageable. I also find identifying my changes vs upstream easier than in rebase scenario: - Use 'git log --first-parent'. Limiting number of commits to show in gitk is also good option for large repositories. - Use 'git merge --no-log --no-ff' to merge with upstream, it strips excessive logs from commit message, --no-ff is necessary only for the first time because fast-forward merges won't be possible. To keep history extremely clean: create empty git repo, make non-empty commit and merge with upstream. And there is hope that keeping independent branches would make "crowd-sourcing magic" more feasible :) I'd prefer to be able to merge code I'm interested in without touching unrelated bits. Thanks, Gleb.