On Mon, Oct 24, 2011 at 6:42 PM, Stefan Schmidt <ste...@datenfreihafen.org> wrote: > No problems showed up during my tests. All four patches have been > applied and pushed.
Thanks for testing and applying! > That only leaves the DfuSe branch outstanding for now. I peaked into > it but did not really started reviewing yet. While git would be fine > mering the branch I'm not going to do this. With the complete > development history and merges it would mess up the history of the > main branch to much. I really see value in keeping a developer history > but in this case I value a sane history on the master branch more. Yes, I agree. An important value of the git history is the possibility of doing git bisecting if a regression is found. This would be more complicated if my work is merged as-is. Bisecting the development of my dfuse work is not so useful, I am pretty confident there are no regressions, and if there are some today, they can be bisected on my branch (which will be put to rest, but will stay archived on gitorious). > I hope you understand this. If you want to squash the changes together > into several patches kind of reflecting the history I would be fine > with that. Rebased on current master that is. The other option is to I tried squashing some changes together but cannot get it to work. I wonder if and how I can do this in git: I started my topic branch at M, and regularly pulled in master (in P and S): A---B---C---D---E---F---G \ \ \ M---N---O---P---Q---R---S Now if O is just a fixup of N I would like to squash them, same for Q and R: A---B---C---D---E---F---G \ \ \ M---N'------P'---Q'-----S' I have tried with git rebase -p but it did not work, I got merge conflicts. Any git experts around who can advice me on this? > add the files directly and make it all into one commit. That does not > feel really fair given the amount of work you did put into it though. > Disadvantages for all ways out here it seems. What about a squashed merge? Please see my master-patches branch where I tried exactly this. All my work is added in one commit in the master branch, but the commit description lists all of my original commits. These commits are also included in the git repo so they can be referenced by their commit ID. git blame will give me my fair share of credit as well :) Still I would have preferred to squash some of these commits, since they are fix-ups or back-and-forth trials, and only makes the development difficult to follow. I also changed some more code at some point (e.g. in dfuload.c) which I later reverted to make the dfuse addition cleaner, but there was some merges in between so these can not be easily squashed away even if I got the above git voodoo to work. Anyway, this is an example of something that could be useful to keep in (some) history - some day someone might look at these functions in dfuload.c and dfuse.c and think they can be merged with a few changes in dfuload.c - then my older code shows an example of this. A full rebase (for instance to current master HEAD) is too difficult. My branch synced with master and libusb branches many times and some of my work was done in parallel in master along the development. It is interesting to look at with "gitk" :) > > In my opinion it might be best to squatch the changes into 5 or 10 > patches that as a compromise between full history and a signle commit. > What way do you prefer? To sum it up, I think a squashed merge will be suitable, but I would have liked to clean up some of my commits if I only knew how. Cheers, Tormod > > regards > Stefan Schmidt _______________________________________________ devel mailing list devel@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/devel
