On Tuesday 06 September 2011, Bill Pringlemeir wrote: > On 4 Sep 2011, h...@pansensack.de wrote: >> Rebasing means automatically rewriting the latest part of your >> commit history so that it is based on a different parent commit. >> This is necessary to avoid conflicts when you pull from an >> integrator who changed your commits, and it is also a nice tool to >> make your history look cleaner before you share it. But is has not >> that much to do with Raphael's particular problem. > > Are you sure? If he is working on DOVE changes (say a branch), > wouldn't he want to rebase with the 'master' so he could see how the > DOVE changes are integrating with whatever was pushed to the > 'master'?
Not necessarily. To integrate new changes from the master branch into his half-done dove branch, he can simply use good old "git merge" instead of "git rebase". The resulting code would be the same, but the resulting history graph would map reality better. You linked to an interesting document in your last mail: http://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html It says there: > There are two main tools that can be used to include changes from one > branch on another: git-merge(1) and git-cherry-pick(1). Merges have > many advantages, so we try to solve as many problems as possible with > merges alone. Cherry-picking is still occasionally useful; While reading this, be aware that a rebase (without its optional features like squashing) is equivalent to a series of cherry-picks. > I think this is something that will change his 'sandbox' concept. I hope so. What I read between Raphael's lines (I may be wrong) sounded like he merged his ready-to-release branches by hand, which would be error-prone and a pain in the rear. > Also, his 'DOVE' branch wouldn't have to be pushed/pulled > to the origin (master remote server). Sure, that's the whole point of decentalized branches. > I am not a git guru, so maybe something is wrong. In principal, there was nothing wrong with your proposal. Raphael could indeed use rebase to keep the underlying code base of his feature branches up-to-date. But I think that: a) one should prefer merge over rebase to do that, b) repeatedly synching feature branches with master is in most cases not necessary at all, and c) this whole discussion misses Raphael's original question about using multiple _directories_ for his multiple branches (which complicates his workflow at the command level but is otherwise equivalent). Bye, Hauke PS, by the way: > git branch master # switch back to master. You switch branches with "git checkout", not "git branch". ------------------------------------------------------------------------------ Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev _______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
