You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@edgent.apache.org by ho...@pacbell.net on 2016/03/08 01:51:57 UTC
Process for committing files
Hi,
I believe I have gotten my repository for apache incubator-quarks set up correctly.
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?
Also, should we open a JIRA issue prior to committing any changes? 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.
Thanks,
Susan
Re: Process for committing files
Posted by ho...@pacbell.net.
Thanks for the info.
I'll give this a go and document what I did in case there are problems or if it can help someone else.
Susan
From: Dan Debrunner <dj...@debrunners.com>
To: "dev@quarks.incubator.apache.org" <de...@quarks.incubator.apache.org>; "home4slc@pacbell.net" <ho...@pacbell.net>
Sent: Monday, March 7, 2016 5:34 PM
Subject: Re: Process for committing files
> On Monday, March 7, 2016 4:52 PM, "home4slc@pacbell.net" <ho...@pacbell.net> 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
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.
Re: Process for committing files
Posted by Dan Debrunner <dj...@debrunners.com>.
> On Tuesday, March 8, 2016 4:33 PM, Dan Debrunner <dj...@debrunners.com> wrote:
>> On Tuesday, March 8, 2016 4:21 PM, "home4slc@pacbell.net"
> <ho...@pacbell.net> wrote:
>
>> Add upstream ....git remote add upstream
>> https://git@git-wip-us.apache.org/repos/asf/incubator-quarks.git
>
>
> You shouldn't need to add that remote, since you cloned from the ASF repo it
> will already have a remote 'origin' that points to the ASF.
You can see this with:
$ git remote -v
origin https://git-wip-us.apache.org/repos/asf/incubator-quarks.git (fetch)
origin https://git-wip-us.apache.org/repos/asf/incubator-quarks.git (push)
Dan.
Re: Process for committing files
Posted by Dan Debrunner <dj...@debrunners.com>.
> On Tuesday, March 8, 2016 4:21 PM, "home4slc@pacbell.net" <ho...@pacbell.net> wrote:
> Add upstream ....git remote add upstream
> https://git@git-wip-us.apache.org/repos/asf/incubator-quarks.git
You shouldn't need to add that remote, since you cloned from the ASF repo it will already have a remote 'origin' that points to the ASF.
Dan.
Re: Fw: Process for committing files
Posted by ho...@pacbell.net.
Ouch .. I even tested by sending a message to myself and it looked okay. I created a JIRA for this:
https://issues.apache.org/jira/browse/QUARKS-15
and attached a text file that lists the steps below. In a way this might be a good way to do it. That way as we move along we can update that document.
Susan
From: "home4slc@pacbell.net" <ho...@pacbell.net>
To: "dev@quarks.incubator.apache.org" <de...@quarks.incubator.apache.org>
Sent: Tuesday, March 8, 2016 5:02 PM
Subject: Re: Fw: Process for committing files
Yep, I sure can, just saw that .. sorry about that. Please let me know how this one looks:
Hi, All,I went ahead with another commit / pull. Here is what I did. Not sure if everyone agrees on this, but it worked for me:
For my initial clone and setting up of my configuration stuffgit clone https://home4slc@git-wip-us.apache.org/repos/asf/incubator-quarks.gitgit config user.name "Susan L. Cline"git config user.email home4slc@apache.org
Since I'm on MacOSX:git config --global credential.helper osxkeychaingit config --global core.autocrlf inputAdd upstream ....git remote add upstream https://git@git-wip-us.apache.org/repos/asf/incubator-quarks.gitgit checkout mastergit fetch upstreamgit rebase upstream/mastergit pushgit checkout -b "console_hover_text" <-- whatever the name of your branch is ...git add console/servlets/src/main/java/quarks/console/servlets/ConsoleJobServlet.java <-- add your file(s)git commit -m 'QUARKS-6 updated objectname for jobmxbean'git checkout mastergit fetch upstreamgit rebase upstream/mastergit pushgit checkout console_hover_text <-- whatever your branch name is git rebase mastergit diff <-- I just do this to make sure there are no conflictsgit push --set-upstream origin console_hover_textNOW look for the commit notice, hang out on the dev list to see if anyone has objections or wants to discuss the commitIf not make the pull ...git checkout mastergit pull --rebasegit checkout console_hover_text <-- your branchgit rebase mastergit checkout mastergit log <-- this is the part I am not sure about, Luciano mentioned to check this .. I don't really understand this. I don't see an entry here for this commitgit merge console_hover_text <-- your branchgit push
Then after that you can do this to delete your branch:git checkout mastergit branch --delete console_hover_text <-- your branchgit push origin --delete console_hover_text <-- your branch
Please let me know if there is a better way.
Cheers,Susan
From: Katherine Marsden <km...@apache.org>
To: dev@quarks.incubator.apache.org
Sent: Tuesday, March 8, 2016 4:58 PM
Subject: Re: Fw: Process for committing files
On 3/8/2016 4:21 PM, home4slc@pacbell.net wrote:
> Hi, All,
> I went ahead with another commit / pull. Here is what I did. Not sure if everyone agrees on this, but it worked for me:
Thank you Susan for doing this. This is a really important email but the
lines seems to have gotten kind of run together at least in my
mailer. The previous emails on this thread were ok. Could you resend
with line breaks?
> For my initial clone and setting up of my configuration stuff
> git clone https://home4slc@git-wip-us.apache.org/repos/asf/incubator-quarks.gitgit config user.name "Susan L. Cline"git config user.email home4slc@apache.org
> Since I'm on MacOSX:
> git config --global credential.helper osxkeychaingit config --global core.autocrlf input
> Add upstream ....git remote add upstream https://git@git-wip-us.apache.org/repos/asf/incubator-quarks.gitgit checkout mastergit fetch upstreamgit rebase upstream/mastergit pushgit checkout -b "console_hover_text" <-- whatever the name of your branch is ...git add console/servlets/src/main/java/quarks/console/servlets/ConsoleJobServlet.java <-- add your file(s)git commit -m 'QUARKS-6 updated objectname for jobmxbean'git checkout mastergit fetch upstreamgit rebase upstream/mastergit pushgit checkout console_hover_text <-- whatever your branch name is git rebase mastergit diff <-- I just do this to make sure there are no conflictsgit push --set-upstream origin console_hover_text
> NOW look for the commit notice, hang out on the dev list to see if anyone has objections or wants to discuss the commitIf not make the pull ...
> git checkout mastergit pull --rebasegit checkout console_hover_text <-- your branchgit rebase mastergit checkout mastergit log <-- this is the part I am not sure about, Luciano mentioned to check this .. I don't really understand this. I don't see an entry here for this commitgit merge console_hover_text <-- your branchgit push
> Then after that you can do this to delete your branch:
> git checkout mastergit branch --delete console_hover_text <-- your branchgit push origin --delete console_hover_text <-- your branch
> Please let me know if there is a better way.Cheers,Susan
>
> ----- Forwarded Message -----
> From: "home4slc@pacbell.net" <ho...@pacbell.net>
> To: "dev@quarks.incubator.apache.org" <de...@quarks.incubator.apache.org>
> Sent: Tuesday, March 8, 2016 11:20 AM
> Subject: Re: Process for committing files
>
> I may have done this wrong ...
> I did 'git log' before I did a git merge and I did not see anything related to my earlier commit. So when you say do a git log, is that what I want?Not to see anything in there related to the commit?
> Here is this commit:http://git-wip-us.apache.org/repos/asf/incubator-quarks/commit/6ddf684a
>
> Is this the correct way so it can be seen in the graphical git tool?
> Susan
>
> From: Luciano Resende <lu...@gmail.com>
> To: dev@quarks.incubator.apache.org; home4slc@pacbell.net
> Cc: Dan Debrunner <dj...@debrunners.com>
> Sent: Tuesday, March 8, 2016 11:00 AM
> Subject: Re: Process for committing files
>
>
>
> On Tue, Mar 8, 2016 at 10:35 AM, <ho...@pacbell.net> wrote:
>
> 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
>
>
>
>
> Let's take an example of QUARKS-7 fix.
> The actual fix was this commit, which you actually see the changes inside :
> http://mail-archives.apache.org/mod_mbox/incubator-quarks-commits/201603.mbox/%3Ca7863d84f45741c4b1425935006fdc5a@git.apache.org%3E
>
> But, because merge was used, then you get an extra commit, where the title does not mean much (only says merge blah, blah, blah) and it also does not have any good context of the changes inside (e.g. diff)
> http://mail-archives.apache.org/mod_mbox/incubator-quarks-commits/201603.mbox/%3Ce0f2df7e3cff49518b97043164509c0d@git.apache.org%3E
>
> If cherry-pick or rebase was used, this extra commit was not going to be present, and when viewed in a graphical git tool, you would see a linear code stream, instead of multiple branches going back and forth from master.
>
> Some other projects have these automated, with some advanced stuff such as automatically close of related jiras, etc...
> https://github.com/lresende/spark/blob/master/dev/merge_spark_pr.py
>
Re: Fw: Process for committing files
Posted by ho...@pacbell.net.
Yep, I sure can, just saw that .. sorry about that. Please let me know how this one looks:
Hi, All,I went ahead with another commit / pull. Here is what I did. Not sure if everyone agrees on this, but it worked for me:
For my initial clone and setting up of my configuration stuffgit clone https://home4slc@git-wip-us.apache.org/repos/asf/incubator-quarks.gitgit config user.name "Susan L. Cline"git config user.email home4slc@apache.org
Since I'm on MacOSX:git config --global credential.helper osxkeychaingit config --global core.autocrlf inputAdd upstream ....git remote add upstream https://git@git-wip-us.apache.org/repos/asf/incubator-quarks.gitgit checkout mastergit fetch upstreamgit rebase upstream/mastergit pushgit checkout -b "console_hover_text" <-- whatever the name of your branch is ...git add console/servlets/src/main/java/quarks/console/servlets/ConsoleJobServlet.java <-- add your file(s)git commit -m 'QUARKS-6 updated objectname for jobmxbean'git checkout mastergit fetch upstreamgit rebase upstream/mastergit pushgit checkout console_hover_text <-- whatever your branch name is git rebase mastergit diff <-- I just do this to make sure there are no conflictsgit push --set-upstream origin console_hover_textNOW look for the commit notice, hang out on the dev list to see if anyone has objections or wants to discuss the commitIf not make the pull ...git checkout mastergit pull --rebasegit checkout console_hover_text <-- your branchgit rebase mastergit checkout mastergit log <-- this is the part I am not sure about, Luciano mentioned to check this .. I don't really understand this. I don't see an entry here for this commitgit merge console_hover_text <-- your branchgit push
Then after that you can do this to delete your branch:git checkout mastergit branch --delete console_hover_text <-- your branchgit push origin --delete console_hover_text <-- your branch
Please let me know if there is a better way.
Cheers,Susan
From: Katherine Marsden <km...@apache.org>
To: dev@quarks.incubator.apache.org
Sent: Tuesday, March 8, 2016 4:58 PM
Subject: Re: Fw: Process for committing files
On 3/8/2016 4:21 PM, home4slc@pacbell.net wrote:
> Hi, All,
> I went ahead with another commit / pull. Here is what I did. Not sure if everyone agrees on this, but it worked for me:
Thank you Susan for doing this. This is a really important email but the
lines seems to have gotten kind of run together at least in my
mailer. The previous emails on this thread were ok. Could you resend
with line breaks?
> For my initial clone and setting up of my configuration stuff
> git clone https://home4slc@git-wip-us.apache.org/repos/asf/incubator-quarks.gitgit config user.name "Susan L. Cline"git config user.email home4slc@apache.org
> Since I'm on MacOSX:
> git config --global credential.helper osxkeychaingit config --global core.autocrlf input
> Add upstream ....git remote add upstream https://git@git-wip-us.apache.org/repos/asf/incubator-quarks.gitgit checkout mastergit fetch upstreamgit rebase upstream/mastergit pushgit checkout -b "console_hover_text" <-- whatever the name of your branch is ...git add console/servlets/src/main/java/quarks/console/servlets/ConsoleJobServlet.java <-- add your file(s)git commit -m 'QUARKS-6 updated objectname for jobmxbean'git checkout mastergit fetch upstreamgit rebase upstream/mastergit pushgit checkout console_hover_text <-- whatever your branch name is git rebase mastergit diff <-- I just do this to make sure there are no conflictsgit push --set-upstream origin console_hover_text
> NOW look for the commit notice, hang out on the dev list to see if anyone has objections or wants to discuss the commitIf not make the pull ...
> git checkout mastergit pull --rebasegit checkout console_hover_text <-- your branchgit rebase mastergit checkout mastergit log <-- this is the part I am not sure about, Luciano mentioned to check this .. I don't really understand this. I don't see an entry here for this commitgit merge console_hover_text <-- your branchgit push
> Then after that you can do this to delete your branch:
> git checkout mastergit branch --delete console_hover_text <-- your branchgit push origin --delete console_hover_text <-- your branch
> Please let me know if there is a better way.Cheers,Susan
>
> ----- Forwarded Message -----
> From: "home4slc@pacbell.net" <ho...@pacbell.net>
> To: "dev@quarks.incubator.apache.org" <de...@quarks.incubator.apache.org>
> Sent: Tuesday, March 8, 2016 11:20 AM
> Subject: Re: Process for committing files
>
> I may have done this wrong ...
> I did 'git log' before I did a git merge and I did not see anything related to my earlier commit. So when you say do a git log, is that what I want?Not to see anything in there related to the commit?
> Here is this commit:http://git-wip-us.apache.org/repos/asf/incubator-quarks/commit/6ddf684a
>
> Is this the correct way so it can be seen in the graphical git tool?
> Susan
>
> From: Luciano Resende <lu...@gmail.com>
> To: dev@quarks.incubator.apache.org; home4slc@pacbell.net
> Cc: Dan Debrunner <dj...@debrunners.com>
> Sent: Tuesday, March 8, 2016 11:00 AM
> Subject: Re: Process for committing files
>
>
>
> On Tue, Mar 8, 2016 at 10:35 AM, <ho...@pacbell.net> wrote:
>
> 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
>
>
>
>
> Let's take an example of QUARKS-7 fix.
> The actual fix was this commit, which you actually see the changes inside :
> http://mail-archives.apache.org/mod_mbox/incubator-quarks-commits/201603.mbox/%3Ca7863d84f45741c4b1425935006fdc5a@git.apache.org%3E
>
> But, because merge was used, then you get an extra commit, where the title does not mean much (only says merge blah, blah, blah) and it also does not have any good context of the changes inside (e.g. diff)
> http://mail-archives.apache.org/mod_mbox/incubator-quarks-commits/201603.mbox/%3Ce0f2df7e3cff49518b97043164509c0d@git.apache.org%3E
>
> If cherry-pick or rebase was used, this extra commit was not going to be present, and when viewed in a graphical git tool, you would see a linear code stream, instead of multiple branches going back and forth from master.
>
> Some other projects have these automated, with some advanced stuff such as automatically close of related jiras, etc...
> https://github.com/lresende/spark/blob/master/dev/merge_spark_pr.py
>
Re: Fw: Process for committing files
Posted by Katherine Marsden <km...@apache.org>.
On 3/8/2016 4:21 PM, home4slc@pacbell.net wrote:
> Hi, All,
> I went ahead with another commit / pull. Here is what I did. Not sure if everyone agrees on this, but it worked for me:
Thank you Susan for doing this. This is a really important email but the
lines seems to have gotten kind of run together at least in my
mailer. The previous emails on this thread were ok. Could you resend
with line breaks?
> For my initial clone and setting up of my configuration stuff
> git clone https://home4slc@git-wip-us.apache.org/repos/asf/incubator-quarks.gitgit config user.name "Susan L. Cline"git config user.email home4slc@apache.org
> Since I'm on MacOSX:
> git config --global credential.helper osxkeychaingit config --global core.autocrlf input
> Add upstream ....git remote add upstream https://git@git-wip-us.apache.org/repos/asf/incubator-quarks.gitgit checkout mastergit fetch upstreamgit rebase upstream/mastergit pushgit checkout -b "console_hover_text" <-- whatever the name of your branch is ...git add console/servlets/src/main/java/quarks/console/servlets/ConsoleJobServlet.java <-- add your file(s)git commit -m 'QUARKS-6 updated objectname for jobmxbean'git checkout mastergit fetch upstreamgit rebase upstream/mastergit pushgit checkout console_hover_text <-- whatever your branch name is git rebase mastergit diff <-- I just do this to make sure there are no conflictsgit push --set-upstream origin console_hover_text
> NOW look for the commit notice, hang out on the dev list to see if anyone has objections or wants to discuss the commitIf not make the pull ...
> git checkout mastergit pull --rebasegit checkout console_hover_text <-- your branchgit rebase mastergit checkout mastergit log <-- this is the part I am not sure about, Luciano mentioned to check this .. I don't really understand this. I don't see an entry here for this commitgit merge console_hover_text <-- your branchgit push
> Then after that you can do this to delete your branch:
> git checkout mastergit branch --delete console_hover_text <-- your branchgit push origin --delete console_hover_text <-- your branch
> Please let me know if there is a better way.Cheers,Susan
>
> ----- Forwarded Message -----
> From: "home4slc@pacbell.net" <ho...@pacbell.net>
> To: "dev@quarks.incubator.apache.org" <de...@quarks.incubator.apache.org>
> Sent: Tuesday, March 8, 2016 11:20 AM
> Subject: Re: Process for committing files
>
> I may have done this wrong ...
> I did 'git log' before I did a git merge and I did not see anything related to my earlier commit. So when you say do a git log, is that what I want?Not to see anything in there related to the commit?
> Here is this commit:http://git-wip-us.apache.org/repos/asf/incubator-quarks/commit/6ddf684a
>
> Is this the correct way so it can be seen in the graphical git tool?
> Susan
>
> From: Luciano Resende <lu...@gmail.com>
> To: dev@quarks.incubator.apache.org; home4slc@pacbell.net
> Cc: Dan Debrunner <dj...@debrunners.com>
> Sent: Tuesday, March 8, 2016 11:00 AM
> Subject: Re: Process for committing files
>
>
>
> On Tue, Mar 8, 2016 at 10:35 AM, <ho...@pacbell.net> wrote:
>
> 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
>
>
>
>
> Let's take an example of QUARKS-7 fix.
> The actual fix was this commit, which you actually see the changes inside :
> http://mail-archives.apache.org/mod_mbox/incubator-quarks-commits/201603.mbox/%3Ca7863d84f45741c4b1425935006fdc5a@git.apache.org%3E
>
> But, because merge was used, then you get an extra commit, where the title does not mean much (only says merge blah, blah, blah) and it also does not have any good context of the changes inside (e.g. diff)
> http://mail-archives.apache.org/mod_mbox/incubator-quarks-commits/201603.mbox/%3Ce0f2df7e3cff49518b97043164509c0d@git.apache.org%3E
>
> If cherry-pick or rebase was used, this extra commit was not going to be present, and when viewed in a graphical git tool, you would see a linear code stream, instead of multiple branches going back and forth from master.
>
> Some other projects have these automated, with some advanced stuff such as automatically close of related jiras, etc...
> https://github.com/lresende/spark/blob/master/dev/merge_spark_pr.py
>
Fw: Process for committing files
Posted by ho...@pacbell.net.
Hi, All,
I went ahead with another commit / pull. Here is what I did. Not sure if everyone agrees on this, but it worked for me:
For my initial clone and setting up of my configuration stuff
git clone https://home4slc@git-wip-us.apache.org/repos/asf/incubator-quarks.gitgit config user.name "Susan L. Cline"git config user.email home4slc@apache.org
Since I'm on MacOSX:
git config --global credential.helper osxkeychaingit config --global core.autocrlf input
Add upstream ....git remote add upstream https://git@git-wip-us.apache.org/repos/asf/incubator-quarks.gitgit checkout mastergit fetch upstreamgit rebase upstream/mastergit pushgit checkout -b "console_hover_text" <-- whatever the name of your branch is ...git add console/servlets/src/main/java/quarks/console/servlets/ConsoleJobServlet.java <-- add your file(s)git commit -m 'QUARKS-6 updated objectname for jobmxbean'git checkout mastergit fetch upstreamgit rebase upstream/mastergit pushgit checkout console_hover_text <-- whatever your branch name is git rebase mastergit diff <-- I just do this to make sure there are no conflictsgit push --set-upstream origin console_hover_text
NOW look for the commit notice, hang out on the dev list to see if anyone has objections or wants to discuss the commitIf not make the pull ...
git checkout mastergit pull --rebasegit checkout console_hover_text <-- your branchgit rebase mastergit checkout mastergit log <-- this is the part I am not sure about, Luciano mentioned to check this .. I don't really understand this. I don't see an entry here for this commitgit merge console_hover_text <-- your branchgit push
Then after that you can do this to delete your branch:
git checkout mastergit branch --delete console_hover_text <-- your branchgit push origin --delete console_hover_text <-- your branch
Please let me know if there is a better way.Cheers,Susan
----- Forwarded Message -----
From: "home4slc@pacbell.net" <ho...@pacbell.net>
To: "dev@quarks.incubator.apache.org" <de...@quarks.incubator.apache.org>
Sent: Tuesday, March 8, 2016 11:20 AM
Subject: Re: Process for committing files
I may have done this wrong ...
I did 'git log' before I did a git merge and I did not see anything related to my earlier commit. So when you say do a git log, is that what I want?Not to see anything in there related to the commit?
Here is this commit:http://git-wip-us.apache.org/repos/asf/incubator-quarks/commit/6ddf684a
Is this the correct way so it can be seen in the graphical git tool?
Susan
From: Luciano Resende <lu...@gmail.com>
To: dev@quarks.incubator.apache.org; home4slc@pacbell.net
Cc: Dan Debrunner <dj...@debrunners.com>
Sent: Tuesday, March 8, 2016 11:00 AM
Subject: Re: Process for committing files
On Tue, Mar 8, 2016 at 10:35 AM, <ho...@pacbell.net> wrote:
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
Let's take an example of QUARKS-7 fix.
The actual fix was this commit, which you actually see the changes inside :
http://mail-archives.apache.org/mod_mbox/incubator-quarks-commits/201603.mbox/%3Ca7863d84f45741c4b1425935006fdc5a@git.apache.org%3E
But, because merge was used, then you get an extra commit, where the title does not mean much (only says merge blah, blah, blah) and it also does not have any good context of the changes inside (e.g. diff)
http://mail-archives.apache.org/mod_mbox/incubator-quarks-commits/201603.mbox/%3Ce0f2df7e3cff49518b97043164509c0d@git.apache.org%3E
If cherry-pick or rebase was used, this extra commit was not going to be present, and when viewed in a graphical git tool, you would see a linear code stream, instead of multiple branches going back and forth from master.
Some other projects have these automated, with some advanced stuff such as automatically close of related jiras, etc...
https://github.com/lresende/spark/blob/master/dev/merge_spark_pr.py
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Process for committing files
Posted by ho...@pacbell.net.
I may have done this wrong ...
I did 'git log' before I did a git merge and I did not see anything related to my earlier commit. So when you say do a git log, is that what I want?Not to see anything in there related to the commit?
Here is this commit:http://git-wip-us.apache.org/repos/asf/incubator-quarks/commit/6ddf684a
Is this the correct way so it can be seen in the graphical git tool?
Susan
From: Luciano Resende <lu...@gmail.com>
To: dev@quarks.incubator.apache.org; home4slc@pacbell.net
Cc: Dan Debrunner <dj...@debrunners.com>
Sent: Tuesday, March 8, 2016 11:00 AM
Subject: Re: Process for committing files
On Tue, Mar 8, 2016 at 10:35 AM, <ho...@pacbell.net> wrote:
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
Let's take an example of QUARKS-7 fix.
The actual fix was this commit, which you actually see the changes inside :
http://mail-archives.apache.org/mod_mbox/incubator-quarks-commits/201603.mbox/%3Ca7863d84f45741c4b1425935006fdc5a@git.apache.org%3E
But, because merge was used, then you get an extra commit, where the title does not mean much (only says merge blah, blah, blah) and it also does not have any good context of the changes inside (e.g. diff)
http://mail-archives.apache.org/mod_mbox/incubator-quarks-commits/201603.mbox/%3Ce0f2df7e3cff49518b97043164509c0d@git.apache.org%3E
If cherry-pick or rebase was used, this extra commit was not going to be present, and when viewed in a graphical git tool, you would see a linear code stream, instead of multiple branches going back and forth from master.
Some other projects have these automated, with some advanced stuff such as automatically close of related jiras, etc...
https://github.com/lresende/spark/blob/master/dev/merge_spark_pr.py
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Process for committing files
Posted by Luciano Resende <lu...@gmail.com>.
On Tue, Mar 8, 2016 at 10:35 AM, <ho...@pacbell.net> wrote:
> 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
>
>
Let's take an example of QUARKS-7 fix.
The actual fix was this commit, which you actually see the changes inside :
http://mail-archives.apache.org/mod_mbox/incubator-quarks-commits/201603.mbox/%3Ca7863d84f45741c4b1425935006fdc5a@git.apache.org%3E
But, because merge was used, then you get an extra commit, where the title
does not mean much (only says merge blah, blah, blah) and it also does not
have any good context of the changes inside (e.g. diff)
http://mail-archives.apache.org/mod_mbox/incubator-quarks-commits/201603.mbox/%3Ce0f2df7e3cff49518b97043164509c0d@git.apache.org%3E
If cherry-pick or rebase was used, this extra commit was not going to be
present, and when viewed in a graphical git tool, you would see a linear
code stream, instead of multiple branches going back and forth from master.
Some other projects have these automated, with some advanced stuff such as
automatically close of related jiras, etc...
https://github.com/lresende/spark/blob/master/dev/merge_spark_pr.py
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Re: Process for committing files
Posted by ho...@pacbell.net.
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 <lu...@gmail.com>
To: dev@quarks.incubator.apache.org; Dan Debrunner <dj...@debrunners.com>
Cc: "home4slc@pacbell.net" <ho...@pacbell.net>
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 <dj...@debrunners.com> wrote:
>
>
>
>
>
> > On Monday, March 7, 2016 4:52 PM, "home4slc@pacbell.net" <
> home4slc@pacbell.net> 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/
Re: Process for committing files
Posted by Luciano Resende <lu...@gmail.com>.
On Mon, Mar 7, 2016 at 5:34 PM, Dan Debrunner <dj...@debrunners.com> wrote:
>
>
>
>
>
> > On Monday, March 7, 2016 4:52 PM, "home4slc@pacbell.net" <
> home4slc@pacbell.net> 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/
Re: Process for committing files
Posted by Dan Debrunner <dj...@debrunners.com>.
> On Monday, March 7, 2016 4:52 PM, "home4slc@pacbell.net" <ho...@pacbell.net> 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
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.