[oi-dev] Pull request : how to get back on track (git lost)

Aurélien Larcher aurelien.larcher at gmail.com
Mon Mar 21 11:25:17 UTC 2016


> Thanks Aurélien,
> Considering the number of commits and the size of the components it was
> easier to cherry-pick one commit at a time rather than rebase or other bulk
> method.
>

Yup yup yup.


>
> But I'm not sure of where I am because when I try to create a pull request
> on github on a specific branch, I can see all the commit from the other
> branch.
>



> Pfiuu, I have to admit that I spend more time to do git/github stuff than
> actually "doing work".
>
As Jim said, there's many schools so you can find documents out there that
> through you in many various direction.
>

Talking about "schools" makes it sound a bit mystic and gives too much
importance to a tool which should be used in a simple manner ;)
The workflow is adapted to the constraints of the build server: send the
components in order (of dependency), one chunk at a time.
Additionally, moderate size of PRs helps the reviewer.

Do not mess with over-complicated git shenanigans, keep it simple:
packaging a component should not require crazy git skills.

For any feature/fix:
1) Resync: `git checkout oi/hipster && git pull --rebase oi/hipster` and
*never* commit on this branch to keep it clean,
2) Branch:  `git checkout -b my_component`,
3) Work work work: `git commit -m "N-th iteration" toto babar` for each
intermediate states until `gmake clobber && gmake publish` passes and the
installed package is functional,
4) Collapse: `git rebase -i HEAD~N` with N number of commits to rewrite
(alternatively give the hash of the commit until which you want to rewrite),
5) Push: `git push -f my_origin my_component` (-f forces rewrite of remote,
beware camembert ! (tm)),
6) PR.

There is no arcane: clone the workspace, address specific issue, clean up
workspace, upstream changes. ;)
If you need to pull more than these ingredients from git then -- most
likely -- something went wrong ;)

In that case, provided that packaging a component is a simple task with no
dependency and < 10 commits, instead of wasting time and torturing yourself
with git manuals and documentation:
1) Create a new branch from oi/hipster: `git checkout oi/hipster && git
checkout -b my_component_anew`,
2) If commits are nicely laid out (i.e one commit == one fix a.k.a
Ghostbusters' rule "Do not cross streams"):
        `git cherry-pick` the commits from your messy branch
    Otherwise copy the files from the original branch:
        `git checkout my_component -- file0 file1 file2 file3` and commit
them in a way that makes sense ;)
3) Collapse,
4) Push,
5) PR.

Of course when you work on a component for which a dependent PR is not
closed yet, base the stem on the relevant branch.

Some random notes from memory:
http://hub.openindiana.ninja/?q=content/quick-start-oi-userland



>
> Best regards.
> Ben
>
> On 21/03/16 12:32, Aurélien Larcher wrote:
>
> Hello,
>
> Hi,
>>
>> I have hard time to get through the git way of doing things right now.
>>
>> So, I forked oi-userland, added components or changes to it and did a
>> pull request.
>> Ok, I understand that I should have done one component at a time.
>>
>
> Whenever there is a dependency of said component at build time yes: PR the
> dependency first.
>
>
>> It seems that the git way of doing this is to create one branch per
>> component which I haven't done.
>>
>> Now I have all my commits in oi/hipster and how can I reach the situation
>> where I can pull request one component only ?
>>
>
> In your case it is easy because there is no dependency between commits.
> I would say the easiest is to create a new branch (git checkout -b
> libconfig) and git cherry-pick the commits related to libconfig.
>
>
>> Is branching per component the best way to make pull request ?
>>
>
> In general features and fixes should live in separate branches yes and one
> for each component: exception is made in case dependencies or lack thereof
> allow several fixes in one PR.
> If you think how the build server works it makes sense.
>
>
>
>>
>> Best regards.
>> Ben
>>
>>
>
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev
>



-- 
---
Praise the Caffeine embeddings
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20160321/f6b90eb8/attachment-0005.html>


More information about the oi-dev mailing list