Date: Mon, 19 Sep 2011 10:47:07 +0300 From: Andriy Gapon <avg@FreeBSD.org> To: Gleb Kurtsou <gleb.kurtsou@gmail.com> Cc: hackers@FreeBSD.org Subject: Re: Fwd: my git development snapshot(s) Message-ID: <4E76F37B.80307@FreeBSD.org> In-Reply-To: <4E76F217.8040901@FreeBSD.org> References: <4E712D11.7040202@FreeBSD.org> <4E75B67E.1000802@FreeBSD.org> <20110918222541.GA86842@tops> <4E76F217.8040901@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E76F37B.80307>