Hi Abdelatif, > Are you assuming that the work is always on a same feature that you submit PRs gradually?
It can be but does not have to be. > What are the cons of deleting branches? Lost work. A botched commit by committer and you have nothing to compare it to. branches are FREE. > What merge commits? I had seen a lot of PR that came into bitbucket in the past with many merge commits from upstream. Rebasing avoids that. (fetch + merge from upstream) Should be fetch and or pull and should only result in a fast forward - with many remotes I use git reset --hard <remote>/master after a fetch. Then as you say, I rebase my wip on it. -----Original Message----- From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com] Sent: Tuesday, January 28, 2020 2:17 PM To: dev@nuttx.apache.org Subject: Re: [DISCUSS] Wrapping up the Workflow document 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 > > >
