[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