dfu-util: Support for DFU ST extensions (DfuSe)
stefan at datenfreihafen.org
Thu Oct 27 00:38:29 CEST 2011
On Tue, 2011-10-25 at 10:55, Tormod Volden wrote:
> On Mon, Oct 24, 2011 at 6:42 PM, Stefan Schmidt <stefan at datenfreihafen.org> wrote:
> > 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
> > 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):
> \ \ \
> Now if O is just a fixup of N I would like to squash them, same for Q and R:
> \ \ \
> 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?
With the explanation below about the merges and work in parallel on
master and the dfuse branch it really looks like git will not be happy
to manually rebase this into a nice patchset.
> > 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 :)
This is actually the first time I hear about a squashed-merge. I
looked at your master-patches branch and it did not look to bad. Sure
the the commitlog is a bit long but the information in there is kept
and the one commit is good for bisection.
> 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" :)
Hmm, to bad. Would have been nice to bring this over in nice pieces
while keeping commitlog informations and bisection available but
throwing out test and debug commits.
> > 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.
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 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.
More information about the devel