[oi-dev] Pull request : how to get back on track (git lost)
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
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
> 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)),
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 ;)
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:
> Best regards.
> On 21/03/16 12:32, Aurélien Larcher wrote:
>> 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.
> oi-dev mailing list
> oi-dev at openindiana.org
Praise the Caffeine embeddings
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the oi-dev