I'll update the berlios and sourceforge to reflect the active
maintainers. We would of course be delighted if anyone
below decides to take a more active role again and re-enabling
them is quickly done.
Lately Spencer Oliver and I have been the de-facto maintainers
of OpenOCD.
These should be
Merged your entire master branch.
http://repo.or.cz/w/openocd.git/blob/HEAD:/HACKING should
be updated with some tips on how to write commit comments:
topic: short comment
blank line
longer comments over several
lines...
You may want to create your own topic branch in that repository and
Hi Kevin,
could you submit a patch that renames cortex-m3.c = cortex-m.c and then
a patch with your Cortex M0 work on top of cortex-m.c?
Thanks!
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
I have deleted ols meddy openocd-swd branch and pushed new branch with
the same name openocd-swd, this one:
-use fresh openocd master head
-is already rebased openocd master with changes from my fork
-has already squashed commits of my work (less commits than before,
more changes at once, no need
Tomek CEDRO wrote:
Im afraid there is not much sense in that interactive rebasing for
such big change - it took me so many hours to split patches and in
result now there are even more patches some new patches patched by old
patches ;] This is far from perfect.
You know that interactive rebase
Hello Peter!
Thank you for all hints :-) Now I know it, but few months ago when I
started using GIT I did not (yet) :-P The changes introduced by my
work could be applied to current openocd/master repository as I wanted
because changes are too big, so I gave up and simply squashed logical
patches
Hi Tomek,
for others to be able to review your work, it is essential
that it is a sequence of small logical changes. This will
also create a much greater degree of continuity in the
official master branch, which is very important to the
maintainers.
We also want to reorder your commits, so that
Well, the changes are bigger than only moving files, because this
impacts code in many different places (i.e. headers inclusion). This
is why I did not split the patches into single step because this takes
too much time that I want to spend on code development and in fact
makes no sense - we
