Hi David,

Are you assuming that the work is always on a same feature that you submit
PRs gradually?

The git usage looks off to me. It would be better to avoid deleting branches
> and using noises merge commits.
>
What are the cons of deleting branches?
What merge commits? I don't understand this last part, do you mean that the
procedure described in the workflow will generate merge commits?
Keeping a WIP branch in synch is missing from the workflow.
Basically same as you described, that should consist of synching master
(fetch + merge from upstream) then rebasing the branch on top of master.


On Tue, Jan 28, 2020 at 8:52 PM David Sidrane <david.sidr...@nscdg.com>
wrote:

> The git usage looks off to me. It would be better to avoid deleting
> branches
> and using noises merge commits.
>
>
> Assume the "upstream" remote is ASF repo
> Assume "prj" remote is my remote
> Assume your code is not in master on your fork.
>
> Submission:
>
> git push prj  master_my_branch
>
> open a PR on git hub (Fill out the template - we need one)
> ...
>
> Your PR comes into master: - this can be as is:no committer  modification
> or
> with modification by the committer.
>
> Reintegration
> Put your current work on top of latest master (with your contribution +
> others)
>
> git checkout master
> git fetch upstream
> git pull upstream master (it should only be a fast forward not merge
> commits) OR git reset --hard upstream/master (no question what you get)
> git checkout master_my_branch
> (optionally if PR codes was modified by committer  - to keep your work
> safe - git -b checkout master_my_branch_PR && git checkout
> master_my_branch)
> (optionally if PR codes was modified by committer  git reset --hard <SHAL
> is
> the parent of master_my_branch started>)
> git rebase master
>
> In reality if the PR was taken as is (no committer  modification) the
> rebase
> on master will only add others changes under your WIP.
>
>
> Alternate for backporting  - Cherry pick your work back to your fork.
>
> This workflow ensures your branch is equal in format to the upstream and no
> others changes. - This may be more stable.
> git checkout master
> git fetch upstream
> git pull upstream master OR git reset --hard upstream/master (no question
> what you get)
>
> git checkout master_my_branch
> git  -b checkout master_my_branch_PR && git checkout master_my_branch
> git reset --hard <SHAL is the parent of master_my_branch started>
> git log master --oneline
> ^C
> git cherry-pick <shal befor the PR commits> ..<last shal>
>
> add -e to change the commit message i.e add [BACKPORT]
>
> David
>
> -----Original Message-----
> From: Miguel Ángel Herranz [mailto:mig...@midokura.com.INVALID]
> Sent: Tuesday, January 28, 2020 8:49 AM
> To: dev@nuttx.apache.org
> Subject: Re: [DISCUSS] Wrapping up the Workflow document
>
> Hi Nathan,
>
> I reviewed the document and added some inlines comments (not sure if they
> are not recommended for use though).
>
> I haven't edited/added any text though, but I will be glad to help if
> needed.
>
> Cheers,
> Miguel
>
> On Fri, Jan 24, 2020 at 4:29 PM Nathan Hartman <hartman.nat...@gmail.com>
> wrote:
>
> > Hi all,
> >
> > The proposed Workflow document (see [1]) has a substantial amount of
> > good information in it.
> >
> > It is not yet 100% percent complete:
> > (1) There are several "REVISIT" notes throughout.
> > (2) A few sections toward the end aren't written yet.
> >
> > However, by the 80-20 rule, I think the most important parts have been
> > written, even if some things are rough around the edges.
> >
> > I have had a LOT of overtime at my $dayjob lately, which has kept me
> > from working much on NuttX. However, I don't want to let the workflow
> > fall by the wayside. I would like to get it wrapped up so we can vote
> > on it soon.
> >
> > Please, could we have some willing volunteers proofread the document,
> > fix some of the "REVISIT" parts, and help push this document that last
> > little bit to get it into a "shippable" state?
> >
> > [1]
> >
> >
> https://cwiki.apache.org/confluence/display/NUTTX/Code+Contribution+Workflow+--+Brennan+Ashton
> > )
> >
> > Thanks,
> > Nathan
> >
>

Reply via email to