Re: rebasing multiple git branches at once

[Carl Sorensen]

On 1/23/10 11:10 PM, "Mark Polesky" <address@hidden> wrote:

> I wrote a little shell script to rebase all my local git
> branches at once.  However, reading the git-pull man page
> makes me wonder if there's not some tragedy waiting to
> happen.  The script is designed for developers who are only
> tracking the `master' branch (translators shouldn't rebase
> too casually anyway).
> 
> So, is this a dumb idea for some reason?  Or is it useful
> enough to add to scripts/auxiliar/?  Right now, I have six
> local branches, and individually doing `git pull -r' was
> just getting me down.  Actually, this script speeds up the
> process even more: it only pulls for `master', then rebases
> the other branches to the updated local master (which is
> much faster than pulling for each).

So does the script rebase all branches in a repository?  I'm sure I wouldn't
like that; I have some branches that are used to keep "old" history around.
I realize that I could rebase them, then go back the previous commit to keep
it in the old state.  But I think I'd prefer to just manage my own rebasing.

I don't try to keep all of my branches up to date.  I manage them
individually.  And then when I'm ready to merge back in, I'll typically do a
git rebase -I to get down to a single commit that varies from the branch
point, then I cherry-pick that commit to master.  This works nicely for
me because I want to have different branches for each issue to work with
Rietveld, but I like to push from master.

But with git, like perl, TMTOWTDI (there's more than one way to do it).  I'm
always interested in seeing how others do it.

Thanks,

Carl