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

[David M. Lloyd]

I think Bob McWhirter had it right when he said "Don't use pull".

There are two basic relevant operations here: merge and rebase.  "Merge" 
means "append these commits after mine".  "Rebase" means "Prepend these 
commits before mine".  Using "merge" and "rebase" and avoiding "pull" is 
nice because "merge" and "rebase" use similar command-line arguments 
(and both require a "fetch" to make sure you're up to date) so there's a 
logical symmetry which is easy to remember.

In addition you can make *sure* that an extra merge commit never happens 
with merge by doing "git merge whatever --ff-only", which will give an 
error if "whatever" needs to be rebased.

As for the integrator doing rebasing - you can really do it either way. 
  In AS7 we've most often been asking the submitter to rebase (via IRC) 
at the time the merge is done.  This may seem impractical but it has 
happened in the past that the merge ultimately fails because of a test 
problem, review issue, etc.  If the submitter has done the rebase, it's 
easier for them to fix any problems, rebase again (if needed), and 
resubmit the request.

Again the mantra: rebase on upstream, merge (--ff-only) downstream. 
Never use "pull" or "merge" without "--ff-only" (in fact, I recommend 
not using "pull" at all, but that's up to you).  Stick to these points 
and merge commits are a thing of the past.

Another note.  If you don't have any local changes, and you just want to 
sync up with upstream, rebase and merge will both do the same thing.  If 
you do have local changes but you don't care about them and you want to 
throw them away, use "git reset --hard upstream/master" followed by "git 
clean -f -d" and you'll be synced up without any issues (make sure 
you're in your project root directory though).  You may do a reset even 
if you don't have changes, it's just extra commands.

Git is the kind of program that you can't learn by just memorizing 
commands - you have to understand what's going on inside (and it's not 
as complex as you might think).  Once you get that, the commands are 
pretty natural, and even obvious in most cases.

If you haven't yet done so, read 
"http://eagain.net/articles/git-for-computer-scientists/".

On 11/18/2010 10:04 AM, 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


-- 
- DML