4:47 p.m.
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
5:04 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
5:43 p.m.
On 18 Nov 2010, at 17:04, 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
Yes, you are correct, this is the right approach. I was under the impression this would
cause issues with the original contributor, if you rebase on upstream, but this is fine
since the topic branch is nuked anyway.
I'll look at updating the pull script.
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
6:10 p.m.
I think you might lose the original author information actually. I'm not sure.
On 18 nov. 2010, at 17:43, Manik Surtani wrote:
On 18 Nov 2010, at 17:04, 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
Yes, you are correct, this is the right approach. I was under the impression this would
cause issues with the original contributor, if you rebase on upstream, but this is fine
since the topic branch is nuked anyway.
I'll look at updating the pull script.
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
6:17 p.m.
New subject: Still confused with the merge messages in Infinispan Git repo
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
- DML
1:44 p.m.
New subject: Still confused with the merge messages in Infinispan Git repo
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Trustin Lee - http://gleamynode.net/
2:38 p.m.
New subject: Still confused with the merge messages in Infinispan Git repo
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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Trustin Lee - http://gleamynode.net/
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
4926
days inactive
4930
days old
infinispan-dev@lists.jboss.org
6 comments
5 participants
participants (5)
-
"이희승 (Trustin Lee)" -
David M. Lloyd -
Emmanuel Bernard -
Galder Zamarreño -
Manik Surtani