Re: [DISCUSS] Wrapping up the Workflow document
On Tue, Jan 28, 2020 at 6:01 PM Nathan Hartman wrote: ... > Please, feel free to improve the text. (Let us know if you need someone to > set up Confluence editing access for you.) > > Thank you very much, > Nathan > My pleasure. I have been busy the last couple of days, but I will try to help complete some of the sections, after reviewing any new comment/email about them. Cheers, /Miguel
Re: [DISCUSS] Wrapping up the Workflow document
On Tue, Jan 28, 2020 at 5:52 PM Gregory Nutt wrote: > We need to get you on the PPMC where it would be easier for you to make > contributions 😀 > Thanks, let's see :) I think for now is ok without becoming PPMC, but anyway I have sent the ICLA in case it could help to contribute in more areas.
Re: [DISCUSS] Wrapping up the Workflow document
The reason the workflow document has too much information is because it contains more than just the procedure to submit a PR/patch. It is intended for both committers and contributors. The "Workflow" section contains the necessary instructions to follow. > Here is my `gitlast` command (it helps me answer the question: What was I > doing?) > > git for-each-ref --count=30 --sort=-committerdate > refs/heads/ --format='%(refname:short)' Thanks for sharing this, it makes a nice summary, especially with the %subject flag. On Wed, Jan 29, 2020 at 7:27 PM David Sidrane wrote: > > Funny! > > I meant real streamlined work instruction. nothing ambiguous and nothing is > not needed. > > Something along the lines of > https://dev.px4.io/master/en/contribute/git_examples.html > > David > > > -Original Message- > From: Nathan Hartman [mailto:hartman.nat...@gmail.com] > Sent: Wednesday, January 29, 2020 11:03 AM > To: dev@nuttx.apache.org > Subject: Re: [DISCUSS] Wrapping up the Workflow document > > On Wed, Jan 29, 2020 at 10:14 AM David Sidrane > wrote: > > My general comment on the Workflow document is it is too much information > > and comments. > > > > Perhaps it can be broken into patch Workflow, git Workflow and githup > > Workflow and then just list the steps. > > (Think in terms of a quckstart guide for nuttx workflow) > > > > In reading it I am still not clear on the work instructions we want to > > ultimately have and are currently using. > > > > Are the current workflow's work instructions (just the steps Alan, Greg > > etc > > have been using) listed out in a document? > > You could add a tl;dr section at the beginning, but I'd urge us to > leave the longer explanations in place. > > Because my problem with terse git workflow instructions is that unless > you're a git guru, they make about as much sense as: > > "To work on this project, all you have to do is fork this from here, > clone that to there, pull this from that remote, push that to this > remote, shove it over here, kick it over there, lift branch A up, yank > branch B back, push branch C sideways, release branch B and let it > snap into branch D, cut branch D off, float it downstream, raise it > three inches, drop it, pull, push, and shove a few more times for good > measure, sacrifice two chickens and a goat, and then open a pull > request. Simple!" > > Cheers, > Nathan
RE: [DISCUSS] Wrapping up the Workflow document
Funny! I meant real streamlined work instruction. nothing ambiguous and nothing is not needed. Something along the lines of https://dev.px4.io/master/en/contribute/git_examples.html David -Original Message- From: Nathan Hartman [mailto:hartman.nat...@gmail.com] Sent: Wednesday, January 29, 2020 11:03 AM To: dev@nuttx.apache.org Subject: Re: [DISCUSS] Wrapping up the Workflow document On Wed, Jan 29, 2020 at 10:14 AM David Sidrane wrote: > My general comment on the Workflow document is it is too much information > and comments. > > Perhaps it can be broken into patch Workflow, git Workflow and githup > Workflow and then just list the steps. > (Think in terms of a quckstart guide for nuttx workflow) > > In reading it I am still not clear on the work instructions we want to > ultimately have and are currently using. > > Are the current workflow's work instructions (just the steps Alan, Greg > etc > have been using) listed out in a document? You could add a tl;dr section at the beginning, but I'd urge us to leave the longer explanations in place. Because my problem with terse git workflow instructions is that unless you're a git guru, they make about as much sense as: "To work on this project, all you have to do is fork this from here, clone that to there, pull this from that remote, push that to this remote, shove it over here, kick it over there, lift branch A up, yank branch B back, push branch C sideways, release branch B and let it snap into branch D, cut branch D off, float it downstream, raise it three inches, drop it, pull, push, and shove a few more times for good measure, sacrifice two chickens and a goat, and then open a pull request. Simple!" Cheers, Nathan
Re: [DISCUSS] Wrapping up the Workflow document
On Wed, Jan 29, 2020 at 10:14 AM David Sidrane wrote: > My general comment on the Workflow document is it is too much information > and comments. > > Perhaps it can be broken into patch Workflow, git Workflow and githup > Workflow and then just list the steps. > (Think in terms of a quckstart guide for nuttx workflow) > > In reading it I am still not clear on the work instructions we want to > ultimately have and are currently using. > > Are the current workflow's work instructions (just the steps Alan, Greg etc > have been using) listed out in a document? You could add a tl;dr section at the beginning, but I'd urge us to leave the longer explanations in place. Because my problem with terse git workflow instructions is that unless you're a git guru, they make about as much sense as: "To work on this project, all you have to do is fork this from here, clone that to there, pull this from that remote, push that to this remote, shove it over here, kick it over there, lift branch A up, yank branch B back, push branch C sideways, release branch B and let it snap into branch D, cut branch D off, float it downstream, raise it three inches, drop it, pull, push, and shove a few more times for good measure, sacrifice two chickens and a goat, and then open a pull request. Simple!" Cheers, Nathan
RE: [DISCUSS] Wrapping up the Workflow document
My general comment on the Workflow document is it is too much information and comments. Perhaps it can be broken into patch Workflow, git Workflow and githup Workflow and then just list the steps. (Think in terms of a quckstart guide for nuttx workflow) In reading it I am still not clear on the work instructions we want to ultimately have and are currently using. Are the current workflow's work instructions (just the steps Alan, Greg etc have been using) listed out in a document? David -Original Message- From: Nathan Hartman [mailto:hartman.nat...@gmail.com] Sent: Wednesday, January 29, 2020 6:47 AM To: dev@nuttx.apache.org Subject: Re: [DISCUSS] Wrapping up the Workflow document On Wed, Jan 29, 2020 at 8:10 AM David Sidrane wrote: > Good tips! git is s powerful it is nice to lean other's tricks. > > Here is my `gitlast` command (it helps me answer the question: What was I > doing?) > > git for-each-ref --count=30 --sort=-committerdate > refs/heads/ --format='%(refname:short)' > > How's about we add a section to the document tips and tricks and share > these? Sure! Feel free to add tips and tricks section if you'd like. Notwithstanding tips and tricks, I'd prefer that we give canonical recommended procedures that everyone can use successfully. Nathan
Re: [DISCUSS] Wrapping up the Workflow document
On Wed, Jan 29, 2020 at 8:10 AM David Sidrane wrote: > Good tips! git is s powerful it is nice to lean other's tricks. > > Here is my `gitlast` command (it helps me answer the question: What was I > doing?) > > git for-each-ref --count=30 --sort=-committerdate > refs/heads/ --format='%(refname:short)' > > How's about we add a section to the document tips and tricks and share > these? Sure! Feel free to add tips and tricks section if you'd like. Notwithstanding tips and tricks, I'd prefer that we give canonical recommended procedures that everyone can use successfully. Nathan
RE: [DISCUSS] Wrapping up the Workflow document
Hi Abdelatif, Good tips! git is s powerful it is nice to lean other's tricks. Here is my `gitlast` command (it helps me answer the question: What was I doing?) git for-each-ref --count=30 --sort=-committerdate refs/heads/ --format='%(refname:short)' How's about we add a section to the document tips and tricks and share these? Thanks for sharing! David -Original Message- From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com] Sent: Tuesday, January 28, 2020 4:50 PM To: dev@nuttx.apache.org Subject: Re: [DISCUSS] Wrapping up the Workflow document Hi David, Sorry for pointing the obvious. :) I do a lot of defensive moves myself too. I never use fetch, pull, mege or push without paramters. I also give my local branches different names than the remotes they are tracking. (Usally just a prefix of the remote) Pushing will then require specifying source and destination (git push src:dest) That's more typing, but prevents some mistakes. On Wed, Jan 29, 2020, 01:38 David Sidrane wrote: > Hi Abdelatif, > > Yes I know. It is a defensive move, on my part, that makes it safe when > working with multiple companies who might not appreciate me sharing their > IP. > > David > > On Tue, Jan 28, 2020, 4:30 PM Abdelatif Guettouche < > abdelatif.guettou...@gmail.com> wrote: > > > 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 > > wrote: > > > > > > Hi Abdelatif > > > > > > > Why do you prefer git reset --hard /master to git merge > > > /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 /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 /master to git merge > > > /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 /ma
Re: [DISCUSS] Wrapping up the Workflow document
Hi David, Sorry for pointing the obvious. :) I do a lot of defensive moves myself too. I never use fetch, pull, mege or push without paramters. I also give my local branches different names than the remotes they are tracking. (Usally just a prefix of the remote) Pushing will then require specifying source and destination (git push src:dest) That's more typing, but prevents some mistakes. On Wed, Jan 29, 2020, 01:38 David Sidrane wrote: > Hi Abdelatif, > > Yes I know. It is a defensive move, on my part, that makes it safe when > working with multiple companies who might not appreciate me sharing their > IP. > > David > > On Tue, Jan 28, 2020, 4:30 PM Abdelatif Guettouche < > abdelatif.guettou...@gmail.com> wrote: > > > 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 > > wrote: > > > > > > Hi Abdelatif > > > > > > > Why do you prefer git reset --hard /master to git merge > > > /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 /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 /master to git merge > > > /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 /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? > > > > > >
Re: [DISCUSS] Wrapping up the Workflow document
Hi Abdelatif, Yes I know. It is a defensive move, on my part, that makes it safe when working with multiple companies who might not appreciate me sharing their IP. David On Tue, Jan 28, 2020, 4:30 PM Abdelatif Guettouche < abdelatif.guettou...@gmail.com> wrote: > 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 > wrote: > > > > Hi Abdelatif > > > > > Why do you prefer git reset --hard /master to git merge > > /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 /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 /master to git merge > > /master after a fetch? > > > > > > > > > > On Tue, Jan 28, 2020 at 11:16 PM David Sidrane > > 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 /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 > > > > wrote: > > > > > > > The git usage looks off to me. It would be better to avoid deleting > > > > branches > > > > and using noises merge commits. > > > > > > > > > > > > Assume the &q
Re: [DISCUSS] Wrapping up the Workflow document
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 wrote: > > Hi Abdelatif > > > Why do you prefer git reset --hard /master to git merge > /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 /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 /master to git merge > /master after a fetch? > > > > > On Tue, Jan 28, 2020 at 11:16 PM David Sidrane > 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 /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 > > 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 &g
RE: [DISCUSS] Wrapping up the Workflow document
Hi Abdelatif > Why do you prefer git reset --hard /master to git merge /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 /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 /master to git merge /master after a fetch? On Tue, Jan 28, 2020 at 11:16 PM David Sidrane 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 /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 > 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 > > > 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
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 /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 /master to git merge /master after a fetch? On Tue, Jan 28, 2020 at 11:16 PM David Sidrane 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 /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 > 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 > 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 > > git log master --oneline > > ^C > > git cherry-pick .. > > > > add -e to change the commit message i.e add [BACKPORT] > > > >
RE: [DISCUSS] Wrapping up the Workflow document
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 /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 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 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 > git log master --oneline > ^C > git cherry-pick .. > > 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 > 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 > > >
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 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 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 > git log master --oneline > ^C > git cherry-pick .. > > 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 > 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 > > >
RE: [DISCUSS] Wrapping up the Workflow document
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 ) 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 git log master --oneline ^C git cherry-pick .. 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 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 >
Re: [DISCUSS] Wrapping up the Workflow document
On Tue, Jan 28, 2020 at 11:49 AM Miguel Ángel Herranz wrote: > 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. Hello Miguel, Thank you for your message. I replied to a couple of your inline comments. (I had no idea there was such a feature!) Please, feel free to improve the text. (Let us know if you need someone to set up Confluence editing access for you.) Thank you very much, Nathan
Re: [DISCUSS] Wrapping up the Workflow document
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. We need to get you on the PPMC where it would be easier for you to make contributions 😀
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 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 >
[DISCUSS] Wrapping up the Workflow document
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
