dfu-util: Support for DFU ST extensions (DfuSe)

[Tormod Volden]

On Mon, Oct 24, 2011 at 6:42 PM, Stefan Schmidt
<stefan at 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