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