If you have a series (or tree) of branches, I wrote a small script to rebase them automatically; however, it falls down when something fails, in so far as you have to finish things manually (for now). Basically, it does this process for N steps and for any number of branches in your local web of commits:
git branch step1-tmp step1 git rebase master step1 git rebase --onto step1 step1-tmp step2 git branch -D step1-tmp Is that what you mean? If so, my script is in the 'buildscripts' branch of my fork on repo.or.cz, named rebase.pl. Here are a few ways I want to see it improved: - figure out the branch tree(s) automatically - avoid leaving temporary branches around - full continuation and abort support, a la 'git rebase' - etc. :) Patches welcome, but I do not plan on adding those scripts to mainline. That branch contains things that I wrote which may be useful to others, but I am not pushing to push any of it. --Z On Mon, 2009-11-23 at 16:34 -0600, Dean Glazeski wrote: > I went ahead and moved everything over as a fork on my own. I'll > leave the other around until this stuff gets hammered out and I'll > remove it at that point. The new play area is > http://repo.or.cz/w/openocd/dnglaze.git. I've rebased everything to > the new origin/master. Is there a good way to rebase two branches > that merge to create another branch? With my current layout, if I > rebase each branch individually, the merge disappears. > > // Dean Glazeski > > > On Mon, Nov 23, 2009 at 3:47 PM, Zach Welch <z...@superlucidity.net> > wrote: > > On Mon, 2009-11-23 at 13:04 -0600, Dean Glazeski wrote: > > Hi all, > > > > I've finished up the implementation and documentation for an > AT91SAM9 > > NAND driver for OpenOCD. In total there are about 34 > patches that > > includes some refactor work for both the NAND controller > layer and the > > ARM NAND I/O pieces. I have the branch posted at > > http://repo.or.cz/w/dnglaze.git under the at91sam9-nand > head. I'm not > > sure what the best approach is for working this into the > tree cause > > this is the biggest change I've attempted to contribute. I > can only > > verify that this works for my Olimex SAM9-L9260 board. Any > > suggestions, testing, or improvements are very welcome. > > > My first question is: would you mind moving your repository to > be a fork > of openocd.git? You need to contact pasky (the maintainer), > but he will > put it in the right place for you. There are several good > reasons for > him to do this, including saving mirroring bandwidth and disk > space on > the server. For us, it puts you in the list with the other > forks, so > others can see when you have pushed new work more easily. > > Anyway, I just pulled your branches and verified each patch > builds okay. > That's a step in the right direction. I'll look more closely > at them > when I am done with my command registration series, which I am > getting > nearly ready to post. > > --Z > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
