Hi Abdelatif, Good tips! git is soooo 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 <remote> src:dest) That's more typing, but prevents some mistakes. On Wed, Jan 29, 2020, 01:38 David Sidrane <david.sidr...@nscdg.com> 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 <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 > > > > > > > > > > > > > >
