I'm following what Luciano recommended, and I am at this point: I would not recommend merging when merge creates an empty commit. I would do something like :
git checkout master <-- done git pull --rebase <-- done git checkout quarks-3 <-- done git rebase master <-- done git checkout master <-- done Now, here you can do two things <-- have not done that yet git merge quarks-3 but make sure with git log or git k that you don't have a empty merge commit like this http://mail-archives.apache.org/mod_mbox/incubator-quarks-commits/201603.mbox/%3C075f51d86d934da5b327675955cf4e53%40git.apache.org%3E Can you explain what you mean by saying it has an empty merge? I don't see what you mean when I look at that link ? Thanks or you could also use git cherry-pick <commit hash> git push From: Luciano Resende <[email protected]> To: [email protected]; Dan Debrunner <[email protected]> Cc: "[email protected]" <[email protected]> Sent: Tuesday, March 8, 2016 10:24 AM Subject: Re: Process for committing files On Mon, Mar 7, 2016 at 5:34 PM, Dan Debrunner <[email protected]> wrote: > > > > > > > On Monday, March 7, 2016 4:52 PM, "[email protected]" < > [email protected]> wrote: > > I believe I have gotten my repository for apache incubator-quarks set up > > > correctly. > Great! > > > It appears we don't have github integration yet, so would it be best to > wait > > for that to happen before we commit any changes? > > There's no reason to wait for github integration to start committing to > the repo. > > > Also, should we open a JIRA issue prior to committing any changes? > > It's probably a judgement call, small changes probably don't always need a > JIRA, don't want to create undue overhead. > Features should have issues, so that the feature is developed "on-list", > not just a code dump at some point with no foreknowledge of what was being > worked on. > Bug-fixes should have an issue so they can be tracked. > > > > If we are > > not waiting for GitHub integration if someone else has already made a > pulland > > can reply with an example git sequence of commands, that would be > helpful. > It's standard git, so what I did was create a branch in my local clone, > make the changes in the branch, commit and push the change to the origin. > That will create a message on the commit mailing list with the changes, e.g. > > > http://mail-archives.apache.org/mod_mbox/incubator-quarks-commits/201603.mbox/%3Ca776b905473f45a9bb0018f95bf6dd8a%40git.apache.org%3E > > <time passes - see below> > > Then, in my local clone, I merged the change into master and pushed. > > git checkout master > git merge quarks-3 > git push > I would not recommend merging when merge creates an empty commit. I would do something like : git checkout master git pull --rebase git checkout quarks-3 git rebase master git checkout master Now, here you can do two things git merge quarks-3 but make sure with git log or git k that you don't have a empty merge commit like this http://mail-archives.apache.org/mod_mbox/incubator-quarks-commits/201603.mbox/%3C075f51d86d934da5b327675955cf4e53%40git.apache.org%3E or you could also use git cherry-pick <commit hash> git push > > That also created a message on the commit list: > > > http://mail-archives.apache.org/mod_mbox/incubator-quarks-commits/201603.mbox/%3C3f93c68d5fe041d98e53e53393ed9458%40git.apache.org%3E > > As a committer you have the right to commit to the repo, but between the > push and the merge is the time frame where anyone can give feedback before > the code is committed to the repo in the master branch (thus used > by/affects everyone). Again it's a judgement call on how long that period > is, order of 72+ hours for major or controversial changes, but less time > for minor changes or those expected to be generally accepted. > > By developing "on-list" you can potentially shorten the 72 hours by > effectively making big changes uncontroversial by letting others see > progress as you go, by working incrementally and pushing frequently to your > branch. Then feedback is given as you go along so the final merge is pretty > much what most folk are expecting. You can always ask for feedback on the > dev list, pointing people to the branch or commit messages. > > > Of course people can still give feedback after the commit, including a -1 > vote to back out a change (with a valid technical reason). > > This is "commit-then-review" style, I believe it's the most efficient, > remember it's all under SCM, so any change can always be backed out. > Dan. > -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
