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 <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
> > > > >
> > > >
>

Reply via email to