On Thu, Apr 2, 2009 at 9:12 PM, Paul Boddie <p...@boddie.org.uk> wrote:
> > "You can do it, but as soon as you go to merge with another repo that > had the unedited commit history, you’ll bump into weirdness (and > probably invalidate your whole reason for rebasing, which was to clean > up the history)." > > - http://adam.blog.heroku.com/past/2008/6/30/rebasing_is_editing_commits/ > > I'm sure other people have their own tales of a similar nature. It is explained in this article why rebase can't be used for something which will be the base for upcoming merges; not all branches are intended this way (but most public ones are). I would say this shows one feature which I think matters a lot in git, more than rebasing itself: multiple branches in a repo, and very cheap branching (in CPU cost, space and workflow) so that you can use private branches for experimentation. cheers, David -- http://mail.python.org/mailman/listinfo/python-list
