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 _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
