Actually, I ran into a possible other option: git rebase -p master
which is supposed to preserve merges by not ignoring them. It seems to work in the limited testing I've done. I'll wait for more commits on origin before I confirm. // Dean Glazeski On Mon, Nov 23, 2009 at 6:24 PM, Zach Welch <[email protected]> wrote: > 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 <[email protected]> > > 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 [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
