[infinispan-dev] Still confused with the merge messages in Infinispan Git repo

Manik Surtani manik at jboss.org
Mon Nov 22 08:38:12 EST 2010


I've updated the helper scripts now to do this - pls use these scripts, reduces the chance of errors!

On 22 Nov 2010, at 12:44, 이희승 (Trustin Lee) wrote:

> Yeah, my bad.  I thought git pushes the merged result as the original
> author's commit (i.e. magical rebasing), but it doesn't seem to do so.
> 
> What's worse is.. I have done it again with ISPN-778 (Galder's one
> again).  Very sorry about that. :-(
> 
> Emmanuel Bernard wrote:
>> I think it was Trustin not rebasing before pushing.
>> 
>> You work on your features in isolation as you've described.
>> And the person that will integrate your pull request need to rebase your branch before merging to master. Let's say it's Trustin.
>> 
>> git checkout master
>> git pull infinispan master
>> git fetch galder
>> git checkout -b ISPN-774 galder/ISPN-774
>> git rebase master
>> //if fails, ask Galder to fix
>> //review, run tests
>> git checkout master 
>> git pull infinispan master 
>> //be sure to be up to date with the latest latest
>> //if it is not, you need to rebase ISPN-774 again
>> git merge ISPN-774
>> git push infinispan master
>> 
>> 
>> On 18 nov. 2010, at 16:47, Galder Zamarreño wrote:
>> 
>>> Hi,
>>> 
>>> I'm confused by this now. Why did Trustin had to merge my ISPN-774 in master? 
>>> 
>>> https://github.com/infinispan/infinispan/commits/master
>>> 
>>> Here's what I did:
>>> 1. Branch for ISPN-779 of master (last commit=X)
>>> 2. Do work, commit (commit=Y).
>>> 3. sync + rebase with master (everything looks good)
>>> 4. push ISPN-779 with -f
>>> 5. Branch for ISPN-774 of master (last commit=X)
>>> // Master here has no ISPN-779 yet - previously, in svn, it would have had but here it does not - is this why the merge has to happen when pulled?
>>> 6. Do work, commit (commit=Z)
>>> 7. sync + rebase with master (up to date already)
>>> 8. push ISPN-774 with -f
>>> 
>>> This is a very common case where you finish a JIRA and you get on with another one immediately. What is the best practice to keep history linear here? I can't just wait for my pull to be dealt with.
>>> 
>>> Maybe when I branched for ISPN-774 in master, I should have rebased of master *and* ispn779_master to keep history linear? But if I did so and then I had to change ISPN-779 for whatever reason, wouldn't it get messy?
>>> 
>>> Thoughts?
>>> --
>>> Galder Zamarreño
>>> Sr. Software Engineer
>>> Infinispan, JBoss Cache
>>> 
>>> 
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
>> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> -- 
> Trustin Lee - http://gleamynode.net/
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org







More information about the infinispan-dev mailing list