Hi Abdelatif > Why do you prefer git reset --hard <remote>/master to git merge <remote>/master after a fetch?
Because with multiple remotes I am sure what local master is set to with a hard reset. There is no possibility of merging remote A into remote B master locally and no merge if I had the wrong remote. David -----Original Message----- From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com] Sent: Tuesday, January 28, 2020 5:04 PM To: dev@nuttx.apache.org Subject: Re: [DISCUSS] Wrapping up the Workflow document Hi David, In the workflow, deleting the branch is only suggested _after_ the PR has been merged. What you are describing is during review, which is missing from the workflow. > I had seen a lot of PR that came into bitbucket in the past with many > merge > commits from upstream. Rebasing avoids that. Yep, still some in Github as well. I personally cherry pick relevant commits from those PRs during review. > 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. With all the work in a separate branch, local fork/master shall always be behind upstream/master, which will result in a fast forward. Why do you prefer git reset --hard <remote>/master to git merge <remote>/master after a fetch? On Tue, Jan 28, 2020 at 11:16 PM David Sidrane <david.sidr...@nscdg.com> wrote: > > 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 > > > > >
