[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: rebasing multiple git branches at once
From: |
Carl Sorensen |
Subject: |
Re: rebasing multiple git branches at once |
Date: |
Sun, 24 Jan 2010 06:49:25 -0700 |
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