linvnguyen at yahoo.com
linvnguyen at yahoo.com
Mon Oct 31 14:04:32 CET 2011
Sent from my iPod
On 31-10-2011, at 20:56, David Morris <david at david-morris.co.uk> wrote:
> Sent from my mobile
> On 31 Oct 2011, at 09:09, Stefan Schmidt <stefan at datenfreihafen.org> wrote:
>> On Sat, 2011-10-29 at 11:35, Tormod Volden wrote:
>>> On Thu, Oct 27, 2011 at 12:38 AM, Stefan Schmidt
>>> <stefan at datenfreihafen.org> wrote:
>>>> Di you try to do a git rebase -i on the branch and remove or squash
>>>> some of the commits you want to get rid of? Due to the merges and your
>>>> other changes I expect not all of the rebases will work. Maybe some
>>>> will work out easily though.
>>> I have tried and using -p, I still have to redo every merge conflict
>>> resolve I had done in the original merges. Which I was hoping to
>>> avoid, since squashing two commits does not change any code from there
>>> on. Maybe "git rerere" is the answer? But it still requires me to redo
>>> the merge conflict resolves once?
>> I've given up after an hour as well. :(
>> This remembers me why I normally have only short term branches and do
>> even rebasing on them. Of course this has other disadvantages like
>> loosing history. :(
>>>> I don't want to put to much work on you for merging this in (you did
>>>> already enough with implementing it). I find the problem interesting
>>>> though and would like to play with it myself a bit. How about this?
>>>> You try some rebase interactive if you are in the mood and I will also
>>>> play with your original branch at the weekend. If nothing better shows
>>>> up I will just merge you squashed merge from master-patches on sunday.
>>> I spent some hours without luck, let's see if you get any further.
>>> Otherwise, yes, let's use my squashed merge and move on.
>> Agreed. It might still be possible to get this sorted out, but after
>> both of us spending time on it I think it is not worth the effort.
>> Better use the time for more productive things. :)
>> Now for the review. I'm hapopy to see that they at least have choosen
>> a different DFU version to distinguish DfuSe from standard DFU. I
>> still need to get out the spec from the windows driver package to read
>> up on it, but I trust you on this part anyway. I'm also happy to see
>> how minimal the impact in main.c is to support this extension. (Thanks
>> to all the ground work you did earlier).
>> So, all in all I'm happy to get this merged. Test with my devices
>> showed up no regressions. I pulled it into master and if no problems
>> show up the next days will make a new release later this week. Thanks
>> again for this major contribution!
>> I wonder what would be the cheapest/easiast available device using DfuSe and
>> being compatible with your implementation. A full pocket oscilloscope might
>> be a bit overkill for playing with it. Any cheap devel board available
>> having the DfuSe enabled bootloader installed?
>> Stefan Schmidt
>> devel mailing list
>> devel at lists.openmoko.org
> devel mailing list
> devel at lists.openmoko.org
More information about the devel