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

Reply via email to