Hi David, You can merge local branch from a different remote than the branch is tracking, giving that the merge is possible of course.
On Wed, Jan 29, 2020 at 12:15 AM David Sidrane <david.sidr...@nscdg.com> wrote: > > 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 > > > > > > >
