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 email@example.com
To unsubscribe from this group, send email to
For more options, visit this group at