Yeah essentially, here is what happened, Galder:
1) Upstream was at a7b639a, as were everyones' forks
2) Work was done resulting in commits f804d87, 38a2b81, 6221342 and 31addcd
3) These commits were pulled in to upstream
4) You then worked on commit 2922faf in your own topic branch
5) Pulling the topic branch into upstream involved a merge, since your topic branch was still based off a7b639a while upstream/master was now on 31addcd
David is right, the approach to prevent (or minimise, anyway) the need for a merge on upstream is that you sync with upstream _before_ you issue your pull request, so that your topic branch knows about the latest goings-on in upstream.
Here is how you can do this:
1) Run the sync_with_upstream.sh script that I wrote. This will make sure your master and 4.2.x branches are up to date.
2) Sync your topic branches by doing:
git checkout topic_master && git rebase master
git checkout topic_4.2.x && git rebase 4.2.x (if you have a 4.2.x version of your topic)
3) Push your topic branches (using the -f flag, since you rebased!) to your remote repo.
I've mentioned this in the worked example on the wiki:
Cheers
Manik
On 11 Nov 2010, at 19:41, David M. Lloyd wrote:
On 11/11/2010 01:27 PM, Galder Zamarreņo wrote:
The merge messages appearing in https://github.com/infinispan/infinispan/commits/master are a bit noisy, aren't they?
To avoid that, people working in branches should use "git rebase" or
"git pull --rebase" to bring in upstream changes, NOT "git merge" or
"git pull" (sans --rebase).
Not only are merge messages noisy but they can make it very hard to
figure out the history of a change.
--
- DML
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
Lead, Infinispan
Lead, JBoss Cache