From owner-freebsd-hackers@FreeBSD.ORG Mon Sep 19 07:47:11 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 42EE0106566B for ; Mon, 19 Sep 2011 07:47:11 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8DADC8FC0A for ; Mon, 19 Sep 2011 07:47:10 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA03903; Mon, 19 Sep 2011 10:47:08 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1R5YZH-000HVF-SH; Mon, 19 Sep 2011 10:47:07 +0300 Message-ID: <4E76F37B.80307@FreeBSD.org> Date: Mon, 19 Sep 2011 10:47:07 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0.2) Gecko/20110907 Thunderbird/6.0.2 MIME-Version: 1.0 To: Gleb Kurtsou References: <4E712D11.7040202@FreeBSD.org> <4E75B67E.1000802@FreeBSD.org> <20110918222541.GA86842@tops> <4E76F217.8040901@FreeBSD.org> In-Reply-To: <4E76F217.8040901@FreeBSD.org> X-Enigmail-Version: undefined Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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: Mon, 19 Sep 2011 07:47:11 -0000 on 19/09/2011 10:41 Andriy Gapon said the following: > on 19/09/2011 01:25 Gleb Kurtsou said the following: >> 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 have used both approaches and for now I prefer my current one (obviously). > But I am really thinking more and more about topgit. Actually, not necessarily > that tool and its implementation, but that kind of concept. > With that approach one has an explicitly defined upstream (or upstreams) and > explicitly defined local changes plus dependency graph for those changes, plus > full history of each change. It's like another dimension to version control, > now you have not only versions of a tree, but also versions of changes to the > tree. topgit implements that idea by having a separate branch for each > (developer defined) change and by stacking those branches on top of each other > to get the tree that has all the dependent changes. > Forgot to add: I think that this is quite close to what you do, but with another layer on top of git to make change management easier. Or harder - if it has bugs or limitations ;-) -- Andriy Gapon