Patch preparation for GSoC evaluation
Christian Mauderer
list at c-mauderer.de
Fri Aug 11 15:34:45 UTC 2017
Am 11.08.2017 um 17:24 schrieb Denis Obrezkov:
> 2017-08-11 17:17 GMT+02:00 Christian Mauderer <list at c-mauderer.de
> <mailto:list at c-mauderer.de>>:
>
> Am 11.08.2017 um 12:14 schrieb Denis Obrezkov:
> > 2017-08-11 11:53 GMT+02:00 Sebastian Huber
> > <sebastian.huber at embedded-brains.de
> <mailto:sebastian.huber at embedded-brains.de>
> > <mailto:sebastian.huber at embedded-brains.de
> <mailto:sebastian.huber at embedded-brains.de>>>:
> >
> > On 11/08/17 11:44, Denis Obrezkov wrote:
> >
> > during our last meeting I didn't completely understand what to do
> > with my commits.
> >
> > I have a set of commits made during the GSoC, they are, of course,
> > a bit chaotic. And the only last few commits make my code look
> > better.
> > So, I have a question: should I take all my commits,
> > merge them into one big commit which changes the state of the code
> > from the initial to the current state? Or how should I clean my
> > commit history?
> >
> >
> > Ideally, there should be a patch set, that can be integrated into
> > RTEMS with clean, self-contained, well described and easy to review
> > patches.
> >
> > --
> > Sebastian Huber, embedded brains GmbH
> >
> > Address : Dornierstr. 4, D-82178 Puchheim, Germany
> > Phone : +49 89 189 47 41-16
> <tel:%2B49%2089%20189%2047%2041-16> <tel:%2B49%2089%20189%2047%2041-16>
> > Fax : +49 89 189 47 41-09
> <tel:%2B49%2089%20189%2047%2041-09> <tel:%2B49%2089%20189%2047%2041-09>
> > E-Mail : sebastian.huber at embedded-brains.de
> <mailto:sebastian.huber at embedded-brains.de>
> > <mailto:sebastian.huber at embedded-brains.de
> <mailto:sebastian.huber at embedded-brains.de>>
> > PGP : Public key available on request.
> >
> > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> >
> >
> > Would it be appropriate to provide a set of patches, for example,
> > for uart, clock and linkcmd related code, but without saving a commit
> > history?
> > I mean - to make a git reset --mixed and then make new commits with
> > relatively
> > clean code.
> > > --
> > Regards, Denis Obrezkov
> >
>
> Hello Denis,
>
> if I understood you correct, that would be the right form for your
> patches. Just remember that you must never change a commit that is
> already in the public master branch. So as long as you are in your own
> development repository you can merge patches. Like Sebastian said, the
> final patches should be compilable, readable and contain only one
> feature.
>
> It's good practice to do the rework of the patches on an extra branch or
> rename the old branch so that it is still there for reference.
>
> Let me shortly describe my typical workflow. Maybe that makes it clear:
>
> If I implement a new feature, the first for me is to create a branch. If
> you haven't done that, that is no problem. Then your branch is just your
> local "master".
>
> I then make a lot of intermediate commits. Most of the time, the commit
> message is just a rough note for myself, what I have done. Often it's
> quite short. Something like "FIXME: Partial function xyz()." If you
> would check out any of them, a lot wouldn't even compile.
>
> As soon as my feature is done, I create a new branch from that (so I can
> keep the old for backup) and then I start to reorder and squash the
> commits on this new branch together. My preferred method for that is a
> "git rebase origin/master" (or on top of the commit before I branched
> the feature). If something goes wrong during the rebase (which happens
> more often then I would like) I just check out my old backup branch and
> do the rebase again.
>
> Most of the time, I check the result of the rebase with a "git diff
> my-old-branch" to make sure I didn't loose any changes.
>
> After the rebase, I have only very few (often only one or two) commits
> left. All of these commits should be compilable. Every commit contains a
> set of changes that belongs together. It's quite possible that it is
> only one patch that adds exactly one driver without the whole history
> how I developed that driver. That patch will be sent to the mailing
> list.
>
> That works quite well for a feature that is developed by a single
> person. There are some other cases too:
>
> If you imported some files from other sources, you should check in these
> sources unchanged in one commit (ideally don't add them to a Makefile or
> similar so that the whole tree is still compilable) and then add your
> changes and enable the compile process in a separate one. So it is easy
> to see what has been changed and maybe update to a more recent version
> of the original sources.
>
> If someone provided parts of the development, you should handle the
> commits of that person in a way that the author is still clearly stated.
>
> I'm sure there are a lot of other edge cases. But these two are the most
> common ones for me.
>
> Please don't hesitate to ask if something isn't clear.
>
> Kind regards
>
> Christian Mauderer
>
>
> Thanks, I am pretty familiar with the workflow, I just wanted to know,
> should I keep
> my commits history (may be there is such a requirement for GSoC)?
>
> --
> Regards, Denis Obrezkov
Hello Denis,
sorry, I didn't wanted to offend you with the detailed description. I
just thought it would be better to offer some details.
The patches that you send to the mailing list for integration into main
RTEMS should be small ones with only one feature per patch. I would
suggest to keep the original history on a branch on github (or wherever
you hosted your GSoC-repo) for at least a few weeks. As far as I know
there is no such requirement by Google. But it might is possible that
your mentor wants the full history during evaluation or that it is
useful if someone continues to work on that or a similar project. Please
ask your mentor regarding that.
Kind regards
Christian Mauderer
More information about the devel
mailing list