For your question, if there are a lot of branches involved, your best bet is probably to write a quick script which runs through the branches on origin deleting the local copies, and recreating them from origin (or if you're daring, using update-ref to directly move them to the proper location). Note that this is actually a very difficult thing to automate - the user probably has some local branches which should *not* be updated from origin, e.g. master. The safest thing to do would be to exclude all by default and provide ways to add branches to the list.
> Also, one should not rebase a branch that has been made publically available. This is generally true, but is probably a bit of an oversimplification - there are reasonable exceptions to this rule. It'd be better to say that branches which have been made publicly available as stable releases should not be rebased. Branches which are clearly development branches can easily be edited until they are ready to be rebased/cherry-picked to master, where they become official, unchangeable history. For an example of this, you need look no farther than git.git, where updates to the 'next' and 'pu' (proposed update) branches are frequently not fast-forwards. Again, these are development branches, essentially drafts of what will eventually be written to the master branch. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Git for human beings" group. To post to this group, send email to git-users@googlegroups.com To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/git-users?hl=en -~----------~----~----~----~------~----~------~--~---
