On Wed, 2009-11-11 at 21:32 +0000, Andrew Rogers wrote: > Hi All, > > I am working a few hours a week trying to get SWD working for the STM32 > Primer2 (R-Link interface). I am happy making changes to the source code > to accomplish this. The problem is that my changes span many files > because OpenOCD is pretty well married up to JTAG. I am taking the > opportunity to create an interface struct that can be type-cast to JTAG > or SWD struct and later extended to UART. The problem I've got is that I > know nothing about git and get problems trying to pull the latest > revisions and merging them with my working copy. I try > > $ git pull > Updating e901cee..2821115 > error: Entry 'src/jtag/core.c' not uptodate. Cannot merge.
You need to commit all of your pending changes? I never see merge failures, because I avoid them by only working on branches. I do not work on my master branch. That way, I can pull new work from upstream into the master branch, then rebase my branches onto it. > and it tells me it can't merge. I suspect that I will run into further > problems as my working copy continues to drift away from the master so I > would like to resolve this soon. I know the problem lies with me not > understanding git, so help is appreciated. The tutorial didn't help me > resolve the above. > > The patch that I will eventually post will be quite big, is this going > to be a problem for the person who merges the patch into the master? Study the various series that I have posted today. They should show you that a problem of the size you describe should probably be broken into dozens of patches, with each one incrementally building the functionality up in the tree. Do _not_ try to produce a monolithic patch, or we will probably not know what to do with all of the changes. Your work would need to be redone, and you will probably be the only person that understands the code well enough to do it. Alternatively, you can produce one patch and be forced to tear it apart into series. Thus, a huge patch will create a problem for you; it will hinder your changes' review and acceptance. Commit early and often. One change per commit. Since you won't get the order right at first, learn how to use (and love) the power of 'git rebase' for reordering, editing, splitting, and combining patches. Each commit needs a meaningful and well-formatted message describing the change. Your series will grow and evolve non-linearly, but you need to present the changes by these rules. Again, see the series that I have recently posted for how to stack your work like this. Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
