Re: Fixing the merge commit in the git repo?
On Thu, Dec 11, 2014 at 07:19:13PM -0500, Clebert Suconic wrote: Right but you can’t ever push -f on an apache branch. you can rebase as much as you like .. and it’s awesome I agree… But others would lose reference if you rebased and pushed -f.. that’s why it’s forbidden at the apache git. And that’s why we are very careful on merging commits. I agree, as it can cause issues for someone who wasn't expecting history to have been fixed. Way back in the day, on a previous project, we had a commit hook that would reject merge commits, forcing the developer to fix their history before pushing anything. Does Apache support such hooks in projects? -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgp_XV0TUjtq5.pgp Description: PGP signature
Re: Fixing the merge commit in the git repo?
On Thu, Dec 11, 2014 at 06:47:06PM -0500, Clebert Suconic wrote: We do a slightly different approach. If you guys are doing git I really think you guys should consider it. 1. create a task branch : git checkout -b my-working-branch 2. create that voodoo that you do 3. when done, rebase your task branch on master : git rebase -i master 4. push to your github fork 5. send a github Pull Request towards the github fork of the apache project 6. Someone else (yeah… someone who was not the original committer) should merge it after review 7 That someone else will do: git merge --no-ff github/pr/PRNumber ( We ellected to have merge committs with our committs, so we always have two people to blame in case things go wrong) If you elect to not have the merge commit like we have, you can simply use git pull.. and that should presever the Hashes from the original commit. 8. The apache bot will close the PR unless you rebased the commit (which you are not supposed to) Why we do that? I - to avoid merge errors like it just happened II - it increases community iii - we have a theory that everyone will do stupid things eventually... this is an extra layer of protection :) You could look at our README for more information: We are still getting started with it and we have based this on how other apache projects are using git and github: https://github.com/apache/activemq-6/blob/master/README.md I like the idea of pull requests and explicit peer reviews for changes. But it's above my pay grade to do anything more than envy such a work flow. :D -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpVnaw8sVRxg.pgp Description: PGP signature
Re: Fixing the merge commit in the git repo?
On 12/12/2014 12:16 PM, Darryl L. Pierce wrote: I like the idea of pull requests and explicit peer reviews for changes. But it's above my pay grade to do anything more than envy such a work flow. :D Pay grade isn't relevant on an Apache project.
Re: Fixing the merge commit in the git repo?
On Fri, Dec 12, 2014 at 01:43:45PM +, Gordon Sim wrote: On 12/12/2014 12:16 PM, Darryl L. Pierce wrote: I like the idea of pull requests and explicit peer reviews for changes. But it's above my pay grade to do anything more than envy such a work flow. :D Pay grade isn't relevant on an Apache project. I was being facetious. I had mentioned pull requests a while back and got the response that (at least then) it wasn't being considered. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpfW3_aoy4LV.pgp Description: PGP signature
Re: Fixing the merge commit in the git repo?
On Dec 12, 2014, at 9:38 AM, Darryl L. Pierce dpie...@redhat.com wrote: On Fri, Dec 12, 2014 at 01:43:45PM +, Gordon Sim wrote: On 12/12/2014 12:16 PM, Darryl L. Pierce wrote: I like the idea of pull requests and explicit peer reviews for changes. But it's above my pay grade to do anything more than envy such a work flow. :D Pay grade isn't relevant on an Apache project. I was being facetious. I had mentioned pull requests a while back and got the response that (at least then) it wasn't being considered. In my experience there is no way to proper work with git without PRs and peer review.. but that’s up to you guys. this has been working very well for us… it has even increased our productivity instead of being an extra step… For instance… I just captured an error from Andy Taylor on this PR: https://github.com/apache/activemq-6/pull/43 https://github.com/apache/activemq-6/pull/43… he then fixed now we are ready to merge it You could even setup automated builds for PRs. and it’s quite easy to do it. no more breaking the build for instance!
Re: Fixing the merge commit in the git repo?
On Fri, Dec 12, 2014 at 09:48:05AM -0500, Clebert Suconic wrote: In my experience there is no way to proper work with git without PRs and peer review.. but that’s up to you guys. I feel like my comment, which was just a joke, might have been taken the wrong way. For that I apologize... -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpdG50SwZL1q.pgp Description: PGP signature
Re: Fixing the merge commit in the git repo?
On Dec 12, 2014, at 9:57 AM, Darryl L. Pierce dpie...@redhat.com wrote: On Fri, Dec 12, 2014 at 09:48:05AM -0500, Clebert Suconic wrote: In my experience there is no way to proper work with git without PRs and peer review.. but that’s up to you guys. I feel like my comment, which was just a joke, might have been taken the wrong way. For that I apologize… Not at all… I was answering based at a later point you mentioned that PRs were considered and decided against. Anyways.. I’m just trying to help you guys and bring you some POV from us since we have been using git longer than you guys… You guys know where to find me if you want to have a chat about it.
Re: Fixing the merge commit in the git repo?
On 12/12/2014 02:38 PM, Darryl L. Pierce wrote: On Fri, Dec 12, 2014 at 01:43:45PM +, Gordon Sim wrote: On 12/12/2014 12:16 PM, Darryl L. Pierce wrote: I like the idea of pull requests and explicit peer reviews for changes. But it's above my pay grade to do anything more than envy such a work flow. :D Pay grade isn't relevant on an Apache project. I was being facetious. I was being pompous.
Re: Fixing the merge commit in the git repo?
On Dec 12, 2014, at 11:44 AM, Gordon Sim g...@redhat.com wrote: On 12/12/2014 02:38 PM, Darryl L. Pierce wrote: On Fri, Dec 12, 2014 at 01:43:45PM +, Gordon Sim wrote: On 12/12/2014 12:16 PM, Darryl L. Pierce wrote: I like the idea of pull requests and explicit peer reviews for changes. But it's above my pay grade to do anything more than envy such a work flow. :D Pay grade isn't relevant on an Apache project. I was being facetious. I was being pompous. Is it Friday yet? Better: is it Xmas break yet?
Re: Fixing the merge commit in the git repo?
On Thu, 2014-12-11 at 11:30 -0500, Darryl L. Pierce wrote: Would it be possible for someone (Rafi?) to fix the merge commits in the Short answer is no! I think you are asking for master's history to be changed and that is: 1) Not possible (fortunately) as the repo is locked down. 2) Not desirable, as you would screw up far more than you would fix. If your workflow relies on a simpler master structure I'm afraid you will just have to change your workflow. Andrew
Re: Fixing the merge commit in the git repo?
On Thu, 2014-12-11 at 17:11 -0500, Darryl L. Pierce wrote: On Thu, Dec 11, 2014 at 04:16:29PM -0500, Clebert Suconic wrote: Rebasing and pushing is not a good option IMO. We have been using pull requests from GitHub and pushing them through Apache. It's working very well for us. Committing directly to Apachea may get you these issues. We can provide you guys more information on how we are doing on activemq6 if you are interested. Additionally, while working on a task branch, to resynch with master do a rebase: $ rebase -i master rather than merging master down onto your task branch. I saw a *lot* of that while examining the merge commits. Rebasing is by far one of the most awesome features of git. I agree and disagree with this simplistic position. If (and only if) your task branch is yours and yours alone and no one has ever relied on it then you can safely rebase it. Actually I find that rebasing is a lot more useful to get my commits in a logical sequence of smaller working commits (by using rebase -i). On the other hand merging topic branches into master is also perfectly sensible to finish off work on a topic branch especially a long lived one. A long lived topic branch will necessarily have some level of merging from master to keep it up to date. On the other hand I agree that merging from master just before merging to master is irritating and pointless. Andrew
Re: Fixing the merge commit in the git repo?
I agree and disagree with this simplistic position. If (and only if) your task branch is yours and yours alone and no one has ever relied on it then you can safely rebase it. Actually I find that rebasing is a lot more useful to get my commits in a logical sequence of smaller working commits (by using rebase -i). +1 … Yes.. as I said earlier.. you can rebase your branch as much as you want. On the other hand merging topic branches into master is also perfectly sensible to finish off work on a topic branch especially a long lived one. +1. That’s why I’m suggesting the PR approach. A long lived topic branch will necessarily have some level of merging from master to keep it up to date. On the other hand I agree that merging from master just before merging to master is irritating and pointless. The apache master can’t be rebased… Period! Work as you wish in your topic branch, your master or whatever you choose… but be careful when you upload to apache/master.. once it’s there you can’t rollback.. unless you ask special privileges from Infra. If you ever need a push -f for a mistake or something.. you will need Infra to do it.
Re: Fixing the merge commit in the git repo?
On Fri, Dec 12, 2014 at 2:15 PM, Andrew Stitcher astitc...@redhat.com wrote: On Thu, 2014-12-11 at 17:11 -0500, Darryl L. Pierce wrote: On Thu, Dec 11, 2014 at 04:16:29PM -0500, Clebert Suconic wrote: Rebasing and pushing is not a good option IMO. We have been using pull requests from GitHub and pushing them through Apache. It's working very well for us. Committing directly to Apachea may get you these issues. We can provide you guys more information on how we are doing on activemq6 if you are interested. Additionally, while working on a task branch, to resynch with master do a rebase: $ rebase -i master rather than merging master down onto your task branch. I saw a *lot* of that while examining the merge commits. Rebasing is by far one of the most awesome features of git. I agree and disagree with this simplistic position. If (and only if) your task branch is yours and yours alone and no one has ever relied on it then you can safely rebase it. Actually I find that rebasing is a lot more useful to get my commits in a logical sequence of smaller working commits (by using rebase -i). On the other hand merging topic branches into master is also perfectly sensible to finish off work on a topic branch especially a long lived one. A long lived topic branch will necessarily have some level of merging from master to keep it up to date. On the other hand I agree that merging from master just before merging to master is irritating and pointless. So what was the right thing to do here? I have to admit I struggled a bit with the git portion of getting the whole thing landed. The changes were (mostly) isolated to a subdirectory, yet whatever git incantations I seemed to come up with forced me to painstakingly hand merge lots of conflicts over and over again. What I ended up doing was mostly stumbled into in an attempt to avoid all that grunge. --Rafael
Re: Fixing the merge commit in the git repo?
On Fri, 2014-12-12 at 14:21 -0500, Clebert Suconic wrote: .. On the other hand I agree that merging from master just before merging to master is irritating and pointless. The apache master can’t be rebased… Period! Work as you wish in your topic branch, your master or whatever you choose… but be careful when you upload to apache/master.. once it’s there you can’t rollback.. unless you ask special privileges from Infra. If you ever need a push -f for a mistake or something.. you will need Infra to do it. I think you are misinterpreting what I said (not that it matters, but it is Friday) - merging from master doesn't imply any sort of rebasing. In some recent merges to master there is an immediately previous merge from master to the topic branch, that is what is unnecessary - because you only need to merge to your local master then push that. Andrew
Re: Fixing the merge commit in the git repo?
On Dec 12, 2014, at 2:44 PM, Andrew Stitcher astitc...@redhat.com wrote: On Fri, 2014-12-12 at 14:21 -0500, Clebert Suconic wrote: .. On the other hand I agree that merging from master just before merging to master is irritating and pointless. The apache master can’t be rebased… Period! Work as you wish in your topic branch, your master or whatever you choose… but be careful when you upload to apache/master.. once it’s there you can’t rollback.. unless you ask special privileges from Infra. If you ever need a push -f for a mistake or something.. you will need Infra to do it. I think you are misinterpreting what I said (not that it matters, but it is Friday) - merging from master doesn't imply any sort of rebasing. In some recent merges to master there is an immediately previous merge from master to the topic branch, that is what is unnecessary - because you only need to merge to your local master then push that. Sure of course… I was just referring that you can’t push -f on apache/master… so you are limited to how much rebasing you can do before pushing into apache copy/master.
Re: Fixing the merge commit in the git repo?
On Fri, Dec 12, 2014 at 02:15:21PM -0500, Andrew Stitcher wrote: On Thu, 2014-12-11 at 17:11 -0500, Darryl L. Pierce wrote: Additionally, while working on a task branch, to resynch with master do a rebase: $ rebase -i master rather than merging master down onto your task branch. I saw a *lot* of that while examining the merge commits. Rebasing is by far one of the most awesome features of git. I agree and disagree with this simplistic position. If (and only if) your task branch is yours and yours alone and no one has ever relied on it then you can safely rebase it. Actually I find that rebasing is a lot more useful to get my commits in a logical sequence of smaller working commits (by using rebase -i). Sorry, I should have clarified that this is my assumption, that a task branch is a private branch that you are working on and not one you're sharing with others. On the other hand merging topic branches into master is also perfectly sensible to finish off work on a topic branch especially a long lived one. A long lived topic branch will necessarily have some level of merging from master to keep it up to date. On the other hand I agree that merging from master just before merging to master is irritating and pointless. Andrew -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpXSHYo3efcH.pgp Description: PGP signature
Re: Fixing the merge commit in the git repo?
On Fri, Dec 12, 2014 at 02:37:53PM -0500, Rafael Schloming wrote: So what was the right thing to do here? I have to admit I struggled a bit with the git portion of getting the whole thing landed. The changes were (mostly) isolated to a subdirectory, yet whatever git incantations I seemed to come up with forced me to painstakingly hand merge lots of conflicts over and over again. What I ended up doing was mostly stumbled into in an attempt to avoid all that grunge. Yeah, that's because there were several spots where master was merged into the javascript branch. So all of the changes that lived in master were already present in javascript (as a part of those merges) but were not in the same deltas as they live on master. So git was seeing the same changes show up in multiple separate commits and needed someone else to decide which was the right one. That's why rebasing your task branch in git is the Right Way(tm) to prepare a task branch for merging up to master. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpQwi65tvZDY.pgp Description: PGP signature
Fixing the merge commit in the git repo?
Would it be possible for someone (Rafi?) to fix the merge commits in the Git repo? I'm working on some stuff and, when I tried to do a rebase I accidentally went a few commits further back and git wanted to then rebase 65 commits... On our individual ends, once it's done, we should be able to just do: $ git pull --rebase and have our individual repos fixed as a result. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpsO2YbjQg7u.pgp Description: PGP signature
Re: Fixing the merge commit in the git repo?
Can you provide a bit more detail? I'm not the most expert git user, so I'm not sure exactly what you're asking for, much less how to do it. --Rafael On Thu, Dec 11, 2014 at 11:30 AM, Darryl L. Pierce dpie...@redhat.com wrote: Would it be possible for someone (Rafi?) to fix the merge commits in the Git repo? I'm working on some stuff and, when I tried to do a rebase I accidentally went a few commits further back and git wanted to then rebase 65 commits... On our individual ends, once it's done, we should be able to just do: $ git pull --rebase and have our individual repos fixed as a result. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Re: Fixing the merge commit in the git repo?
On Thu, Dec 11, 2014 at 02:35:05PM -0500, Rafael Schloming wrote: Can you provide a bit more detail? I'm not the most expert git user, so I'm not sure exactly what you're asking for, much less how to do it. In my case, my usual workflow is to do small changes and commit them locally. If a change goes with a commit a few back I'll do: $ git commit -a --fixup=[early commit's hash] Then, when I'm ready to commit I'll do: $ git rebase -i HEAD~[# of commits to process] --autosquash and git will put the commits in the right order so I can squash them down. Normally I just do HEAD~25 rather than counting the commits since we usually had a nice, linear stream of commits in our old repo that was cloned from Subversion. But when I did it this time that the commits overlapped with this merge commit: ===[snip]=== commit e8029597b825e49ee5ab2b7c8bd5d042e57321bb Merge: db437cf a5cb27e Author: Rafael Schloming r...@alum.mit.edu Date: Fri Nov 28 08:43:03 2014 -0500 Merge branch 'javascript' ===[snip]=== This made git them try to rebase all of those changes, which numbered up to about 60 or so commits that are out of sequence. So I had to abort that rebase and count the commits instead and do it again. When merging branches, etc. we can avoid this if, before merging branch A into master we go to branch A and rebase it on master. That way we avoid merge commits like this. To fix it, you would need to: 1. git rebase -i HEAD~[# of commits to the merge above] 2. when it pops up the list of commits, just save (you're not going to re-order them at that point) 3. check for any merge commits, dual adds or deletes with git status 4. fix any issues that you see: fix merges, etc. 5. git add (or del) files as needed 6. git rebase --continue 7. go to 3 as needed until all is fixed -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpGCgaCe_wBM.pgp Description: PGP signature
Re: Fixing the merge commit in the git repo?
Rebasing and pushing is not a good option IMO. We have been using pull requests from GitHub and pushing them through Apache. It's working very well for us. Committing directly to Apachea may get you these issues. We can provide you guys more information on how we are doing on activemq6 if you are interested. On Dec 11, 2014, at 16:13, Darryl L. Pierce dpie...@redhat.com wrote: On Thu, Dec 11, 2014 at 02:35:05PM -0500, Rafael Schloming wrote: Can you provide a bit more detail? I'm not the most expert git user, so I'm not sure exactly what you're asking for, much less how to do it. In my case, my usual workflow is to do small changes and commit them locally. If a change goes with a commit a few back I'll do: $ git commit -a --fixup=[early commit's hash] Then, when I'm ready to commit I'll do: $ git rebase -i HEAD~[# of commits to process] --autosquash and git will put the commits in the right order so I can squash them down. Normally I just do HEAD~25 rather than counting the commits since we usually had a nice, linear stream of commits in our old repo that was cloned from Subversion. But when I did it this time that the commits overlapped with this merge commit: ===[snip]=== commit e8029597b825e49ee5ab2b7c8bd5d042e57321bb Merge: db437cf a5cb27e Author: Rafael Schloming r...@alum.mit.edu Date: Fri Nov 28 08:43:03 2014 -0500 Merge branch 'javascript' ===[snip]=== This made git them try to rebase all of those changes, which numbered up to about 60 or so commits that are out of sequence. So I had to abort that rebase and count the commits instead and do it again. When merging branches, etc. we can avoid this if, before merging branch A into master we go to branch A and rebase it on master. That way we avoid merge commits like this. To fix it, you would need to: 1. git rebase -i HEAD~[# of commits to the merge above] 2. when it pops up the list of commits, just save (you're not going to re-order them at that point) 3. check for any merge commits, dual adds or deletes with git status 4. fix any issues that you see: fix merges, etc. 5. git add (or del) files as needed 6. git rebase --continue 7. go to 3 as needed until all is fixed -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Re: Fixing the merge commit in the git repo?
On Thu, Dec 11, 2014 at 04:16:29PM -0500, Clebert Suconic wrote: Rebasing and pushing is not a good option IMO. We have been using pull requests from GitHub and pushing them through Apache. It's working very well for us. Committing directly to Apachea may get you these issues. We can provide you guys more information on how we are doing on activemq6 if you are interested. So if we don't want to go back and fix history (which is fine) can we take steps to avoid pushing merge commits in future? It's just an ugly and confusing situation to get into with them. For anybody who's not familiar with a good git workflow: 1. create a task branch : git checkout -b my-working-branch 2. create that voodoo that you do 3. when done, rebase your task branch on master : git rebase -i master 4. checkout master and merge : git checkout master; git merge my-working-branch 5. make sure master is up to date : git pull --rebase 6. push your changes 7. profit! This way we don't have those ugly diamonds in the gitg graph and issues like this in future. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpHx0DDTzxNY.pgp Description: PGP signature
Re: Fixing the merge commit in the git repo?
On Thu, Dec 11, 2014 at 04:16:29PM -0500, Clebert Suconic wrote: Rebasing and pushing is not a good option IMO. We have been using pull requests from GitHub and pushing them through Apache. It's working very well for us. Committing directly to Apachea may get you these issues. We can provide you guys more information on how we are doing on activemq6 if you are interested. Additionally, while working on a task branch, to resynch with master do a rebase: $ rebase -i master rather than merging master down onto your task branch. I saw a *lot* of that while examining the merge commits. Rebasing is by far one of the most awesome features of git. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpeYfzyU3P0t.pgp Description: PGP signature
Re: Fixing the merge commit in the git repo?
We do a slightly different approach. If you guys are doing git I really think you guys should consider it. 1. create a task branch : git checkout -b my-working-branch 2. create that voodoo that you do 3. when done, rebase your task branch on master : git rebase -i master 4. push to your github fork 5. send a github Pull Request towards the github fork of the apache project 6. Someone else (yeah… someone who was not the original committer) should merge it after review 7 That someone else will do: git merge --no-ff github/pr/PRNumber ( We ellected to have merge committs with our committs, so we always have two people to blame in case things go wrong) If you elect to not have the merge commit like we have, you can simply use git pull.. and that should presever the Hashes from the original commit. 8. The apache bot will close the PR unless you rebased the commit (which you are not supposed to) Why we do that? I - to avoid merge errors like it just happened II - it increases community iii - we have a theory that everyone will do stupid things eventually... this is an extra layer of protection :) You could look at our README for more information: We are still getting started with it and we have based this on how other apache projects are using git and github: https://github.com/apache/activemq-6/blob/master/README.md
Re: Fixing the merge commit in the git repo?
On Dec 11, 2014, at 5:11 PM, Darryl L. Pierce dpie...@redhat.com wrote: On Thu, Dec 11, 2014 at 04:16:29PM -0500, Clebert Suconic wrote: Rebasing and pushing is not a good option IMO. We have been using pull requests from GitHub and pushing them through Apache. It's working very well for us. Committing directly to Apachea may get you these issues. We can provide you guys more information on how we are doing on activemq6 if you are interested. Additionally, while working on a task branch, to resynch with master do a rebase: $ rebase -i master rather than merging master down onto your task branch. I saw a *lot* of that while examining the merge commits. Rebasing is by far one of the most awesome features of git. Right but you can’t ever push -f on an apache branch. you can rebase as much as you like .. and it’s awesome I agree… But others would lose reference if you rebased and pushed -f.. that’s why it’s forbidden at the apache git. And that’s why we are very careful on merging commits.
