rails-devel

[Rails-devel] Fwd: 1830 RSM

[Stefan F. <ste...@we...>]

Erik:
I forward you a report of a potentially critical bug: It does not allow 
selling the director of the NYNH given that the operating director owns 
the president share only and 2 other players have 20% each and Pool 
having 30% only.

This bug can be reproduced back to 1.5.3, unfortunately the save file is 
not fully loadable under 1.5.2.

I suspect this is related to the changes for 1835 at that time, I have 
to admit that I cannot fully understand the code used to create the 
actions for selling, so you might be in a better position to find this bug.

Thanks,
Stefan


-------- Original Message --------
Subject: Fwd: 1830 RSM
Date: Tue, 31 Jan 2012 09:30:48 -0500
From: Bob Probst <bob...@gm...>
To: stefan.frey <ste...@we...>

Stefan, a friend of mine found this issue.  I haven't confirmed it yet
but he's pretty thorough.

I'm sure you can contact him directly if you have any questions


---------- Forwarded message ----------
From: "Ing. Antonio Baracca" <ant...@gm...>
Date: Tue, 31 Jan 2012 14:53:37 +0100
Subject: Fwd: 1830 RSM
To: Bob Probst <bob...@gm...>
Cc: Palmiro Matteini <pma...@om...>

Hi Bob,
we have found a major bug on the 1830 module.
The current player cannot sell 10% of NYNH from his president
certificate (remaining so with only 10% of NYNH and shifting the
presidency of the corporation).
I attach a saved file of the current 1830 game with the bug point.
I have seen you are currently in contact with programmers.
Can you please report to them this bug?
Thank you in advance.
Regards
Antonio



Inizio messaggio inoltrato:

> Da: "Palmiro Matteini" <pma...@om...>
> Data: 31 gennaio 2012 14.23.26 GMT+01.00
> A: "Ing. Antonio Baracca" <ant...@gm...>
> Oggetto: Re: 1830 RSM
>
> Eccolo.
> Ciao.
>
> Palmiro Matteini
> pma...@om...
> ----- Original Message -----
> From: Ing. Antonio Baracca
> To: Palmiro Matteini
> Sent: Tuesday, January 31, 2012 11:46 AM
> Subject: Re: 1830 RSM
>
> Mandami la salvata che ci guardo
>
>
> Antonio Baracca
> ant...@ti...
>
> Il giorno 31/gen/2012, alle ore 09:28, "Palmiro Matteini" <pma...@om...> ha scritto:
>
>> Ciao Antonio.
>> Nella partita che stiamo facendo con Rail in ASGS, è successa una cosa strana.
>> Glauco ha venduto azioni della NYNH tenendosi solo il certificato della presidenza del 20%.
>> Al giro successivo c'erano altri giocatori che avevano il 20% e nel bank pool c'era il 30%.
>> Il programma stranamente non gli ha permesso di vendere il certificato della presidenza.
>> C'è un buco nel programma ?
>> Ciao.
>>
>> Palmiro Matteini
>> pma...@om...

Antonio Baracca
ant...@gm...

Re: [Rails-devel] Fwd: 1830 RSM Fix included

[<Dr....@t-...>]

Hi Stefan &Erik,  i believe the following small fix solves that
problem,  Please run your usual test scenarios :) And maybe we should
add that save file as a test !  Regards, Martin  diff --git
a/rails/game/StockRound.java b/rails/game/StockRound.java
index 037d2cc..25d05ce 100644
--- a/rails/game/StockRound.java
+++ b/rails/game/StockRound.java
@@ -464,7 +464,7 @@
              */
             // Take care for max. 4 share units per share
             compName = company.getName();
-            int[] shareCountPerUnit =
playerPortfolio.getCertificateTypeCountsPerCompany(compName, false);
+            int[] shareCountPerUnit =
playerPortfolio.getCertificateTypeCountsPerCompany(compName,
true);//Martin: we need to make sure we find the president only share
to sell in the next step!
             // Check the price. If a cert was sold before this turn,
the original price is still valid.
             price = getCurrentSellPrice(company);   

	  Von: Stefan Frey <ste...@we...>
 An: Erik Vos <eri...@xs...>
 Cc: an 18xx game <rai...@li...>
 Betreff: [Rails-devel] Fwd: 1830 RSM
 Datum: Tue, 31 Jan 2012 16:15:26 +0100

 Erik:
 I forward you a report of a potentially critical bug: It does not
allow 
 selling the director of the NYNH given that the operating director
owns 
 the president share only and 2 other players have 20% each and Pool 
 having 30% only.

 This bug can be reproduced back to 1.5.3, unfortunately the save file
is 
 not fully loadable under 1.5.2.

 I suspect this is related to the changes for 1835 at that time, I
have 
 to admit that I cannot fully understand the code used to create the 
 actions for selling, so you might be in a better position to find
this bug.

 Thanks,
 Stefan

 -------- Original Message --------
 Subject: Fwd: 1830 RSM
 Date: Tue, 31 Jan 2012 09:30:48 -0500
 From: Bob Probst 
 To: stefan.frey 

 Stefan, a friend of mine found this issue.  I haven't confirmed it
yet
 but he's pretty thorough.

 I'm sure you can contact him directly if you have any questions

 ---------- Forwarded message ----------
 From: "Ing. Antonio Baracca" 
 Date: Tue, 31 Jan 2012 14:53:37 +0100
 Subject: Fwd: 1830 RSM
 To: Bob Probst 
 Cc: Palmiro Matteini 

 Hi Bob,
 we have found a major bug on the 1830 module.
 The current player cannot sell 10% of NYNH from his president
 certificate (remaining so with only 10% of NYNH and shifting the
 presidency of the corporation).
 I attach a saved file of the current 1830 game with the bug point.
 I have seen you are currently in contact with programmers.
 Can you please report to them this bug?
 Thank you in advance.
 Regards
 Antonio

 Inizio messaggio inoltrato:

 > Da: "Palmiro Matteini" 
 > Data: 31 gennaio 2012 14.23.26 GMT+01.00
 > A: "Ing. Antonio Baracca" 
 > Oggetto: Re: 1830 RSM
 >
 > Eccolo.
 > Ciao.
 >
 > Palmiro Matteini
 > pma...@om...
 > ----- Original Message -----
 > From: Ing. Antonio Baracca
 > To: Palmiro Matteini
 > Sent: Tuesday, January 31, 2012 11:46 AM
 > Subject: Re: 1830 RSM
 >
 > Mandami la salvata che ci guardo
 >
 >
 > Antonio Baracca
 > ant...@ti...
 >
 > Il giorno 31/gen/2012, alle ore 09:28, "Palmiro Matteini"  ha
scritto:
 >
 >> Ciao Antonio.
 >> Nella partita che stiamo facendo con Rail in ASGS, è successa una
cosa strana.
 >> Glauco ha venduto azioni della NYNH tenendosi solo il certificato
della presidenza del 20%.
 >> Al giro successivo c'erano altri giocatori che avevano il 20% e
nel bank pool c'era il 30%.
 >> Il programma stranamente non gli ha permesso di vendere il
certificato della presidenza.
 >> C'è un buco nel programma ?
 >> Ciao.
 >>
 >> Palmiro Matteini
 >> pma...@om...

 Antonio Baracca
 ant...@gm...

[Rails-devel] FW: Fwd: 1830 RSM Fix included

[Erik V. <eri...@xs...>]

I just have pushed a different fix: two statements had to be swapped.

Martin, your fix would only allow selling 20%, but in fact the president can also sell only 10% if he wants.

Erik.

From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Tuesday, January 31, 2012 9:15 PM
To: Development list for Rails: an 18xx game; Erik Vos; Stefan Frey
Subject: Re: [Rails-devel] Fwd: 1830 RSM Fix included

Hi Stefan &Erik,
i believe the following small fix solves that problem,
Please run your usual test scenarios :) And maybe we should add that save file as a test !
Regards,
Martin
diff --git a/rails/game/StockRound.java b/rails/game/StockRound.java
index 037d2cc..25d05ce 100644
--- a/rails/game/StockRound.java
+++ b/rails/game/StockRound.java
@@ -464,7 +464,7 @@
              */
             // Take care for max. 4 share units per share
             compName = company.getName();
-            int[] shareCountPerUnit = playerPortfolio.getCertificateTypeCountsPerCompany(compName, false);
+            int[] shareCountPerUnit = playerPortfolio.getCertificateTypeCountsPerCompany(compName, true);//Martin: we need to make sure we find the president only share to sell in the next step!
             // Check the price. If a cert was sold before this turn, the original price is still valid.
             price = getCurrentSellPrice(company);
 
Von: Stefan Frey <ste...@we...>
An: Erik Vos <eri...@xs...>
Cc: an 18xx game <rai...@li...>
Betreff: [Rails-devel] Fwd: 1830 RSM
Datum: Tue, 31 Jan 2012 16:15:26 +0100
Erik:
I forward you a report of a potentially critical bug: It does not allow 
selling the director of the NYNH given that the operating director owns 
the president share only and 2 other players have 20% each and Pool 
having 30% only.

This bug can be reproduced back to 1.5.3, unfortunately the save file is 
not fully loadable under 1.5.2.

I suspect this is related to the changes for 1835 at that time, I have 
to admit that I cannot fully understand the code used to create the 
actions for selling, so you might be in a better position to find this bug.

Thanks,
Stefan


-------- Original Message --------
Subject: Fwd: 1830 RSM
Date: Tue, 31 Jan 2012 09:30:48 -0500
From: Bob Probst 
To: stefan.frey 

Stefan, a friend of mine found this issue. I haven't confirmed it yet
but he's pretty thorough.

I'm sure you can contact him directly if you have any questions


---------- Forwarded message ----------
From: "Ing. Antonio Baracca" 
Date: Tue, 31 Jan 2012 14:53:37 +0100
Subject: Fwd: 1830 RSM
To: Bob Probst 
Cc: Palmiro Matteini 

Hi Bob,
we have found a major bug on the 1830 module.
The current player cannot sell 10% of NYNH from his president
certificate (remaining so with only 10% of NYNH and shifting the
presidency of the corporation).
I attach a saved file of the current 1830 game with the bug point.
I have seen you are currently in contact with programmers.
Can you please report to them this bug?
Thank you in advance.
Regards
Antonio



Inizio messaggio inoltrato:

> Da: "Palmiro Matteini" 
> Data: 31 gennaio 2012 14.23.26 GMT+01.00
> A: "Ing. Antonio Baracca" 
> Oggetto: Re: 1830 RSM
>
> Eccolo.
> Ciao.
>
> Palmiro Matteini
> pma...@om...
> ----- Original Message -----
> From: Ing. Antonio Baracca
> To: Palmiro Matteini
> Sent: Tuesday, January 31, 2012 11:46 AM
> Subject: Re: 1830 RSM
>
> Mandami la salvata che ci guardo
>
>
> Antonio Baracca
> ant...@ti...
>
> Il giorno 31/gen/2012, alle ore 09:28, "Palmiro Matteini" ha scritto:
>
>> Ciao Antonio.
>> Nella partita che stiamo facendo con Rail in ASGS, è successa una cosa strana.
>> Glauco ha venduto azioni della NYNH tenendosi solo il certificato della presidenza del 20%.
>> Al giro successivo c'erano altri giocatori che avevano il 20% e nel bank pool c'era il 30%.
>> Il programma stranamente non gli ha permesso di vendere il certificato della presidenza.
>> C'è un buco nel programma ?
>> Ciao.
>>
>> Palmiro Matteini
>> pma...@om...

Antonio Baracca
ant...@gm...
 

Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included

[Stefan F. <ste...@we...>]

Erik,
Yes I remember: I doubt that it was your intention ;-)

However I still surprised that it was possible that
code written by Frederick ended up under a commit from you.
And this commit was not a merge commit, but the bug-fix release.

Maybe you did amend the merge commit with your fix or other way round?
Brett do you have a story that explains it?

Stefan


On 02/01/2012 10:27 AM, Erik Vos wrote:
> Stefan,
>
> As I explained before:  I had accidentally pulled [from master] while checked out in my local nonmodal branch, which had some unmerged commits.  The merge occurred when I was rebasing everything back in order.
> If you know a way to protect myself against such mistakes, please tell me.  I don't know if autosetuprebase will fix that, but I have added it anyway.
>
> BTW my git pull and push are set up for master only.  I'm keeping all other remote branches out of the way.
>
> Erik.
>
>> -----Original Message-----
>> From: Stefan Frey [mailto:ste...@we...]
>> Sent: Wednesday, February 01, 2012 8:08 AM
>> To: rai...@li...
>> Subject: Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included
>>
>> Erik:
>> the patch works perfectly: However you the commit you used to fix it is
>> tainted by your merge:
>>
>> If you check a26c986 it changes 15 files and contains many changes which
>> where actually from Frederick.
>>
>> My guess it that is somehow related to the fact that you merge your changes
>> instead of using rebase to add them at the end of the repository?
>>
>> Have you set the git config branch.autosetuprebase=always?
>> This was recommended by Brett Lentz and avoids the frequent merges you
>> have used recently.
>>
>> For current case I will recreate a commit which only contains your fix for the
>> 1.6.x branch.
>>
>> Stefan
>>
>> On 01/31/2012 10:25 PM, Erik Vos wrote:
>>> I just have pushed a different fix: two statements had to be swapped.
>>>
>>> Martin, your fix would only allow selling 20%, but in fact the president can
>> also sell only 10% if he wants.
>>>
>>> Erik.
>>>
>>> From: Dr....@t-... [mailto:Dr.Martin.Brumm@t-
>> online.de]
>>> Sent: Tuesday, January 31, 2012 9:15 PM
>>> To: Development list for Rails: an 18xx game; Erik Vos; Stefan Frey
>>> Subject: Re: [Rails-devel] Fwd: 1830 RSM Fix included
>>>
>>> Hi Stefan&Erik,
>>> i believe the following small fix solves that problem, Please run your
>>> usual test scenarios :) And maybe we should add that save file as a test !
>>> Regards,
>>> Martin
>>> diff --git a/rails/game/StockRound.java b/rails/game/StockRound.java
>>> index 037d2cc..25d05ce 100644
>>> --- a/rails/game/StockRound.java
>>> +++ b/rails/game/StockRound.java
>>> @@ -464,7 +464,7 @@
>>>                 */
>>>                // Take care for max. 4 share units per share
>>>                compName = company.getName();
>>> -            int[] shareCountPerUnit =
>> playerPortfolio.getCertificateTypeCountsPerCompany(compName, false);
>>> +            int[] shareCountPerUnit =
>> playerPortfolio.getCertificateTypeCountsPerCompany(compName,
>> true);//Martin: we need to make sure we find the president only share to
>> sell in the next step!
>>>                // Check the price. If a cert was sold before this turn, the original
>> price is still valid.
>>>                price = getCurrentSellPrice(company);
>>>
>>> Von: Stefan Frey<ste...@we...>
>>> An: Erik Vos<eri...@xs...>
>>> Cc: an 18xx game<rai...@li...>
>>> Betreff: [Rails-devel] Fwd: 1830 RSM
>>> Datum: Tue, 31 Jan 2012 16:15:26 +0100
>>> Erik:
>>> I forward you a report of a potentially critical bug: It does not
>>> allow selling the director of the NYNH given that the operating
>>> director owns the president share only and 2 other players have 20%
>>> each and Pool having 30% only.
>>>
>>> This bug can be reproduced back to 1.5.3, unfortunately the save file
>>> is not fully loadable under 1.5.2.
>>>
>>> I suspect this is related to the changes for 1835 at that time, I have
>>> to admit that I cannot fully understand the code used to create the
>>> actions for selling, so you might be in a better position to find this bug.
>>>
>>> Thanks,
>>> Stefan
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Fwd: 1830 RSM
>>> Date: Tue, 31 Jan 2012 09:30:48 -0500
>>> From: Bob Probst
>>> To: stefan.frey
>>>
>>> Stefan, a friend of mine found this issue. I haven't confirmed it yet
>>> but he's pretty thorough.
>>>
>>> I'm sure you can contact him directly if you have any questions
>>>
>>>
>>> ---------- Forwarded message ----------
>>> From: "Ing. Antonio Baracca"
>>> Date: Tue, 31 Jan 2012 14:53:37 +0100
>>> Subject: Fwd: 1830 RSM
>>> To: Bob Probst
>>> Cc: Palmiro Matteini
>>>
>>> Hi Bob,
>>> we have found a major bug on the 1830 module.
>>> The current player cannot sell 10% of NYNH from his president
>>> certificate (remaining so with only 10% of NYNH and shifting the
>>> presidency of the corporation).
>>> I attach a saved file of the current 1830 game with the bug point.
>>> I have seen you are currently in contact with programmers.
>>> Can you please report to them this bug?
>>> Thank you in advance.
>>> Regards
>>> Antonio
>>>
>>>
>>>
>>> Inizio messaggio inoltrato:
>>>
>>>> Da: "Palmiro Matteini"
>>>> Data: 31 gennaio 2012 14.23.26 GMT+01.00
>>>> A: "Ing. Antonio Baracca"
>>>> Oggetto: Re: 1830 RSM
>>>>
>>>> Eccolo.
>>>> Ciao.
>>>>
>>>> Palmiro Matteini
>>>> pma...@om...
>>>> ----- Original Message -----
>>>> From: Ing. Antonio Baracca
>>>> To: Palmiro Matteini
>>>> Sent: Tuesday, January 31, 2012 11:46 AM
>>>> Subject: Re: 1830 RSM
>>>>
>>>> Mandami la salvata che ci guardo
>>>>
>>>>
>>>> Antonio Baracca
>>>> ant...@ti...
>>>>
>>>> Il giorno 31/gen/2012, alle ore 09:28, "Palmiro Matteini" ha scritto:
>>>>
>>>>> Ciao Antonio.
>>>>> Nella partita che stiamo facendo con Rail in ASGS, è successa una cosa
>> strana.
>>>>> Glauco ha venduto azioni della NYNH tenendosi solo il certificato della
>> presidenza del 20%.
>>>>> Al giro successivo c'erano altri giocatori che avevano il 20% e nel bank
>> pool c'era il 30%.
>>>>> Il programma stranamente non gli ha permesso di vendere il certificato
>> della presidenza.
>>>>> C'è un buco nel programma ?
>>>>> Ciao.
>>>>>
>>>>> Palmiro Matteini
>>>>> pma...@om...
>>>
>>> Antonio Baracca
>>> ant...@gm...
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> -------- Keep Your Developer Skills Current with LearnDevNow!
>>> The most comprehensive online learning library for Microsoft
>>> developers is just $99.99! Visual Studio, SharePoint, SQL - plus
>>> HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when
>> you subscribe now!
>>> http://p.sf.net/sfu/learndevnow-d2d
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers is
>> just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro
>> Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included

[Frederick W. <fre...@go...>]

Not regarding this specific issue but more as a request for alignment
regarding hotfix procedure:

I'm not a GIT expert but this is what I would do to provide a hotfix
for a release branch (1.6.x - locally available remote tracking branch
assumed):

git checkout -b Hotfix-xyz 1.6.x
...do changes...
git commit -a -m "Hotfix-xyz..."
git checkout 1.6.x
git pull
git merge --no-ff Hotfix-xyz
git push
git checkout master
git pull
git merge --no-ff Hotfix-xyz
git push
git branch -D Hotfix-xyz

To me, switching to auto-rebase is very dangerous if we are working on
several remote tracking branches and might pull from one of these
local branches to the other. If not (or if there is only one remote
tracking branch as for Erik), switching to auto-rebase appears to be
ok.

--Frederick

Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included

[Stefan F. <ste...@we...>]

Frederick:
I am not a git-expert myself, but you could either trust Brett who uses
git in his day-job (at least what I understood) or check some sources on 
the Internet:

Especially this q&a on stackoverflow:
http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions

Shows the workflow using rebase in the first listing (and yours in the 
second).

You still merge your features, however you FIRST rebase your new feature 
on top of the master repo.

Maybe Brett can shed even more light on this issues (again).

Stefan


On 02/01/2012 02:06 PM, Frederick Weld wrote:
> Not regarding this specific issue but more as a request for alignment
> regarding hotfix procedure:
>
> I'm not a GIT expert but this is what I would do to provide a hotfix
> for a release branch (1.6.x - locally available remote tracking branch
> assumed):
>
> git checkout -b Hotfix-xyz 1.6.x
> ...do changes...
> git commit -a -m "Hotfix-xyz..."
> git checkout 1.6.x
> git pull
> git merge --no-ff Hotfix-xyz
> git push
> git checkout master
> git pull
> git merge --no-ff Hotfix-xyz
> git push
> git branch -D Hotfix-xyz
>
> To me, switching to auto-rebase is very dangerous if we are working on
> several remote tracking branches and might pull from one of these
> local branches to the other. If not (or if there is only one remote
> tracking branch as for Erik), switching to auto-rebase appears to be
> ok.
>
> --Frederick
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included

[brett l. <bre...@gm...>]

On Wed, Feb 1, 2012 at 8:28 AM, Stefan Frey <ste...@we...> wrote:
> Frederick:
> I am not a git-expert myself, but you could either trust Brett who uses
> git in his day-job (at least what I understood) or check some sources on
> the Internet:
>

Correct. I've been using git on a daily basis for 3-4 years now. I
recently switched employers, and now git is an even bigger part of my
daily work life. ;-)

> Especially this q&a on stackoverflow:
> http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions
>
> Shows the workflow using rebase in the first listing (and yours in the
> second).
>
> You still merge your features, however you FIRST rebase your new feature
> on top of the master repo.
>

This is correct.

The whole idea behind rebase is to re-align your feature branch's
history so that the diff is *ONLY* your changes. That way, when you
merge the branches, you're not considering someone else's work and
being forced to resolve any merge conflicts for work you didn't create
(and probably aren't the expert on).

To do this, git rewinds your feature branch back to the common point
in both branch's history, then it replays the remote branch's changes
onto your feature branch, and THEN it re-applies your local commits on
top of the new, updated history.

Under most circumstances, this is a good thing. This allows you to see
whether some new commits have made your local commits un-merge-able.
You get to resolve the merge conflicts in your local feature branch
*before* merging your local feature branch into the publicly published
branches.

> Maybe Brett can shed even more light on this issues (again).
>
> Stefan
>

---Brett.

>
> On 02/01/2012 02:06 PM, Frederick Weld wrote:
>> Not regarding this specific issue but more as a request for alignment
>> regarding hotfix procedure:
>>
>> I'm not a GIT expert but this is what I would do to provide a hotfix
>> for a release branch (1.6.x - locally available remote tracking branch
>> assumed):
>>
>> git checkout -b Hotfix-xyz 1.6.x
>> ...do changes...
>> git commit -a -m "Hotfix-xyz..."
>> git checkout 1.6.x
>> git pull
>> git merge --no-ff Hotfix-xyz
>> git push
>> git checkout master
>> git pull
>> git merge --no-ff Hotfix-xyz
>> git push
>> git branch -D Hotfix-xyz
>>
>> To me, switching to auto-rebase is very dangerous if we are working on
>> several remote tracking branches and might pull from one of these
>> local branches to the other. If not (or if there is only one remote
>> tracking branch as for Erik), switching to auto-rebase appears to be
>> ok.
>>
>> --Frederick
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included

[Frederick W. <fre...@go...>]

Brett:
So what would be the git command sequence when wanting to create a fix
in a separate branch which is to be merged back to both 1.6.x and
master (You could copy-paste aforementioned order as a template)?

If rebasing is done before merging into 1.6.x and master, the hotfix
commit will be altered (and not be the same as used in 1.6.x).
Probably no big issue as 1.6.x and master will never be merged again.

--Frederick

Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included

[Stefan F. <ste...@we...>]

Frederick:
My solution for this currently is to git cherry-pick the
bug-fix commit into the 1.6.x branch.

Usually bug fixes do not effect lots of file, and if there
is a conflict it is usually easy to resolve.

But the main reason for this solution is that usually I receive the 
bug-fixes as already merged into master.

Should it not be possible to first rebase on master, then revert that 
rebase and then rebase on 1.6.x.?

However I am curious if Brett has a better recommendation.

Stefan



On 02/01/2012 03:48 PM, Frederick Weld wrote:
> Brett:
> So what would be the git command sequence when wanting to create a fix
> in a separate branch which is to be merged back to both 1.6.x and
> master (You could copy-paste aforementioned order as a template)?
>
> If rebasing is done before merging into 1.6.x and master, the hotfix
> commit will be altered (and not be the same as used in 1.6.x).
> Probably no big issue as 1.6.x and master will never be merged again.
>
> --Frederick
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included

[brett l. <bre...@gm...>]

So...  there's a couple ways to do this, depending on what end-result we want.

As Stefan mentions, cherry-picking is one of the better options for
this. Changes should be merged into master, and then cherry-picked
into the feature branch. Ideally, all cherry-picks should use the "-x"
flag, which appends a line to your commit message saying where it was
cherry-picked from. This is important because, otherwise, cherry-picks
are commits that are wholly disconnected from their parent commit, so
the chain of history is not well-preserved with cherry-picks.

Remember, git cares about *history* far more than it does about any
particular change. It tracks changes by parent-child relationships, so
we need to be aware of when we're breaking that relationship.

This is also what makes rebasing against two different branches
somewhat problematic. Here's an example. (Hopefully my bad ascii art
displays correctly on your side)

Imagine commits in master look something like this:

A -> B -> C -> D

Then, we create a release, and create a maintenance branch for the release:

A->B->C->D->H-I
           \
            ->E->F-G

Now, let's say more work is done, including some work I've done on a
feature in my own local branch:

                      ->J->K->L
                     /
A->B->C->D->H-I->M->N
           \
            ->E->F-G


So...  now let's say I rebase my local branch against master. This
rewinds my local branch to the common point in both branch's history
(H), then replays the commits that were in master so my local branch
"catches up", like so:

                                   ->J->K->L
                                  /
A->B->C->D->H-I->M->N
           \
            ->E->F-G

Git has reordered the history on my local branch. This is important
because most traditional SCMs don't allow you to rewrite history. Git
does, but it expects you to understand that this is what you're doing.

This allows me to now merge my changes into master cleanly at the most
current point in the history:

                                   ->J->K->L
                                  /               \
A->B->C->D->H-I->M->N---------------->O
           \
            ->E->F-G

Note, O is a merge commit that has no content of it's own, but marks
the point in the history where there is multiple parents.

So, now the question is... how do I get my changes into the maintenance branch?

If I rebase my local tree a second time, git will again rewind to the
common ancestor (C) and... it will see all of the new changes from
master as if they were changes I had made in my local branch, because
they are not common to the maintenance branch. This means that a bunch
of stuff from master will be brought into the maintenance branch.

Maybe that's what we want, and maybe it isn't.

However, the alternative is to cherry-pick *only* my changes out of
either master or my local branch, divorce them from the history, and
append them into the maintenance branch, like so:


                                   ->J->K->L
                                  /               \
A->B->C->D->H-I->M->N---------------->O
           \
            ->E->F-G->P(J)->Q(K)->R(L)


Hopefully that helps. :-)

---Brett.



On Wed, Feb 1, 2012 at 9:56 AM, Stefan Frey <ste...@we...> wrote:
> Frederick:
> My solution for this currently is to git cherry-pick the
> bug-fix commit into the 1.6.x branch.
>
> Usually bug fixes do not effect lots of file, and if there
> is a conflict it is usually easy to resolve.
>
> But the main reason for this solution is that usually I receive the
> bug-fixes as already merged into master.
>
> Should it not be possible to first rebase on master, then revert that
> rebase and then rebase on 1.6.x.?
>
> However I am curious if Brett has a better recommendation.
>
> Stefan
>
>
>
> On 02/01/2012 03:48 PM, Frederick Weld wrote:
>> Brett:
>> So what would be the git command sequence when wanting to create a fix
>> in a separate branch which is to be merged back to both 1.6.x and
>> master (You could copy-paste aforementioned order as a template)?
>>
>> If rebasing is done before merging into 1.6.x and master, the hotfix
>> commit will be altered (and not be the same as used in 1.6.x).
>> Probably no big issue as 1.6.x and master will never be merged again.
>>
>> --Frederick
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] git branching maintenance release (was; 1830 RSM Fix included)

[Stefan F. <ste...@we...>]

Brett:
thanks for this excellent explanation.
So I got lucky that I have used a valid workflow from the beginning. And 
indeed I applied the -x flag.

However I am still wondering if it would be possible to "rebase back to 
the past"?


                                      ->J->K->L
                                     /               \
  A->B->C->D->H-I->M->N---------------->O
              \
               ->E->F-G

If I understand rebase correctly the command (assume that J to L is 
branch feature, A to O to master and G to maintenance)

rebase --onto maintenance master feature

should end up with same result?

A->B->C->D->H-I->M->N---------------->O
              \
               ->E->F-G->P(J)->Q(K)->R(L)

Stefan



On 02/01/2012 05:37 PM, brett lentz wrote:
> So...  there's a couple ways to do this, depending on what end-result we want.
>
> As Stefan mentions, cherry-picking is one of the better options for
> this. Changes should be merged into master, and then cherry-picked
> into the feature branch. Ideally, all cherry-picks should use the "-x"
> flag, which appends a line to your commit message saying where it was
> cherry-picked from. This is important because, otherwise, cherry-picks
> are commits that are wholly disconnected from their parent commit, so
> the chain of history is not well-preserved with cherry-picks.
>
> Remember, git cares about *history* far more than it does about any
> particular change. It tracks changes by parent-child relationships, so
> we need to be aware of when we're breaking that relationship.
>
> This is also what makes rebasing against two different branches
> somewhat problematic. Here's an example. (Hopefully my bad ascii art
> displays correctly on your side)
>
> Imagine commits in master look something like this:
>
> A ->  B ->  C ->  D
>
> Then, we create a release, and create a maintenance branch for the release:
>
> A->B->C->D->H-I
>             \
>              ->E->F-G
>
> Now, let's say more work is done, including some work I've done on a
> feature in my own local branch:
>
>                        ->J->K->L
>                       /
> A->B->C->D->H-I->M->N
>             \
>              ->E->F-G
>
>
> So...  now let's say I rebase my local branch against master. This
> rewinds my local branch to the common point in both branch's history
> (H), then replays the commits that were in master so my local branch
> "catches up", like so:
>
>                                     ->J->K->L
>                                    /
> A->B->C->D->H-I->M->N
>             \
>              ->E->F-G
>
> Git has reordered the history on my local branch. This is important
> because most traditional SCMs don't allow you to rewrite history. Git
> does, but it expects you to understand that this is what you're doing.
>
> This allows me to now merge my changes into master cleanly at the most
> current point in the history:
>
>                                     ->J->K->L
>                                    /               \
> A->B->C->D->H-I->M->N---------------->O
>             \
>              ->E->F-G
>
> Note, O is a merge commit that has no content of it's own, but marks
> the point in the history where there is multiple parents.
>
> So, now the question is... how do I get my changes into the maintenance branch?
>
> If I rebase my local tree a second time, git will again rewind to the
> common ancestor (C) and... it will see all of the new changes from
> master as if they were changes I had made in my local branch, because
> they are not common to the maintenance branch. This means that a bunch
> of stuff from master will be brought into the maintenance branch.
>
> Maybe that's what we want, and maybe it isn't.
>
> However, the alternative is to cherry-pick *only* my changes out of
> either master or my local branch, divorce them from the history, and
> append them into the maintenance branch, like so:
>
>
>                                     ->J->K->L
>                                    /               \
> A->B->C->D->H-I->M->N---------------->O
>             \
>              ->E->F-G->P(J)->Q(K)->R(L)
>
>
> Hopefully that helps. :-)
>
> ---Brett.
>
>
>
> On Wed, Feb 1, 2012 at 9:56 AM, Stefan Frey<ste...@we...>  wrote:
>> Frederick:
>> My solution for this currently is to git cherry-pick the
>> bug-fix commit into the 1.6.x branch.
>>
>> Usually bug fixes do not effect lots of file, and if there
>> is a conflict it is usually easy to resolve.
>>
>> But the main reason for this solution is that usually I receive the
>> bug-fixes as already merged into master.
>>
>> Should it not be possible to first rebase on master, then revert that
>> rebase and then rebase on 1.6.x.?
>>
>> However I am curious if Brett has a better recommendation.
>>
>> Stefan
>>
>>
>>
>> On 02/01/2012 03:48 PM, Frederick Weld wrote:
>>> Brett:
>>> So what would be the git command sequence when wanting to create a fix
>>> in a separate branch which is to be merged back to both 1.6.x and
>>> master (You could copy-paste aforementioned order as a template)?
>>>
>>> If rebasing is done before merging into 1.6.x and master, the hotfix
>>> commit will be altered (and not be the same as used in 1.6.x).
>>> Probably no big issue as 1.6.x and master will never be merged again.
>>>
>>> --Frederick
>>>
>>> ------------------------------------------------------------------------------
>>> Keep Your Developer Skills Current with LearnDevNow!
>>> The most comprehensive online learning library for Microsoft developers
>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>> http://p.sf.net/sfu/learndevnow-d2d
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] git branching maintenance release (was; 1830 RSM Fix included)

[brett l. <bre...@gm...>]

The problem is all of the commits in between (The C->N commits). This
is, admittedly, where my experience with git runs a little thin, so
please feel free to test this out on your local repositories. (Hooray
distributed SCM!)

I *believe* what will happen if you rebase onto the maintenance
branch, then merge after first having rebased onto master, will look
something like this...


                                        ->J->K->L
                                       /               \
  A->B->C->D->H->I->M->N---------------->O
              \
               ->E->F-G--------------------------------------->P
                            \                                       /.
                             ->D->H->I->M->N->J->K->L


Where P is another merge commit, just like O.

Feel free to test this out and prove me right/wrong. :-) However, I'm
pretty sure this is what will happen because git doesn't know or care
about the context of the commits, but only cares about their
parent/child relationships. So, once you've rebased your local branch
onto the latest master, the parent commit of J *is* N, and so when you
rebase onto the maintenance branch, it sees that the shared point C
begins to diverge at D/E and, therefore from D to N is considered "new
work" relative to the maintenance branch, exactly the same as the J to
L commits that you really want on the maintenance branch.

I think the way around this is to create *two* private feature
branches, rebase one onto master and rebase the other onto the
maintenance branch, and either merge or cherry-pick your commits
between your two private feature branches in whatever way makes sense
in your work flow.

---Brett.



On Wed, Feb 1, 2012 at 12:37 PM, Stefan Frey <ste...@we...> wrote:
> Brett:
> thanks for this excellent explanation.
> So I got lucky that I have used a valid workflow from the beginning. And
> indeed I applied the -x flag.
>
> However I am still wondering if it would be possible to "rebase back to
> the past"?
>
>
>                                      ->J->K->L
>                                     /               \
>  A->B->C->D->H-I->M->N---------------->O
>              \
>               ->E->F-G
>
> If I understand rebase correctly the command (assume that J to L is
> branch feature, A to O to master and G to maintenance)
>
> rebase --onto maintenance master feature
>
> should end up with same result?
>
> A->B->C->D->H-I->M->N---------------->O
>              \
>               ->E->F-G->P(J)->Q(K)->R(L)
>
> Stefan
>
>
>
> On 02/01/2012 05:37 PM, brett lentz wrote:
>> So...  there's a couple ways to do this, depending on what end-result we want.
>>
>> As Stefan mentions, cherry-picking is one of the better options for
>> this. Changes should be merged into master, and then cherry-picked
>> into the feature branch. Ideally, all cherry-picks should use the "-x"
>> flag, which appends a line to your commit message saying where it was
>> cherry-picked from. This is important because, otherwise, cherry-picks
>> are commits that are wholly disconnected from their parent commit, so
>> the chain of history is not well-preserved with cherry-picks.
>>
>> Remember, git cares about *history* far more than it does about any
>> particular change. It tracks changes by parent-child relationships, so
>> we need to be aware of when we're breaking that relationship.
>>
>> This is also what makes rebasing against two different branches
>> somewhat problematic. Here's an example. (Hopefully my bad ascii art
>> displays correctly on your side)
>>
>> Imagine commits in master look something like this:
>>
>> A ->  B ->  C ->  D
>>
>> Then, we create a release, and create a maintenance branch for the release:
>>
>> A->B->C->D->H-I
>>             \
>>              ->E->F-G
>>
>> Now, let's say more work is done, including some work I've done on a
>> feature in my own local branch:
>>
>>                        ->J->K->L
>>                       /
>> A->B->C->D->H-I->M->N
>>             \
>>              ->E->F-G
>>
>>
>> So...  now let's say I rebase my local branch against master. This
>> rewinds my local branch to the common point in both branch's history
>> (H), then replays the commits that were in master so my local branch
>> "catches up", like so:
>>
>>                                     ->J->K->L
>>                                    /
>> A->B->C->D->H-I->M->N
>>             \
>>              ->E->F-G
>>
>> Git has reordered the history on my local branch. This is important
>> because most traditional SCMs don't allow you to rewrite history. Git
>> does, but it expects you to understand that this is what you're doing.
>>
>> This allows me to now merge my changes into master cleanly at the most
>> current point in the history:
>>
>>                                     ->J->K->L
>>                                    /               \
>> A->B->C->D->H-I->M->N---------------->O
>>             \
>>              ->E->F-G
>>
>> Note, O is a merge commit that has no content of it's own, but marks
>> the point in the history where there is multiple parents.
>>
>> So, now the question is... how do I get my changes into the maintenance branch?
>>
>> If I rebase my local tree a second time, git will again rewind to the
>> common ancestor (C) and... it will see all of the new changes from
>> master as if they were changes I had made in my local branch, because
>> they are not common to the maintenance branch. This means that a bunch
>> of stuff from master will be brought into the maintenance branch.
>>
>> Maybe that's what we want, and maybe it isn't.
>>
>> However, the alternative is to cherry-pick *only* my changes out of
>> either master or my local branch, divorce them from the history, and
>> append them into the maintenance branch, like so:
>>
>>
>>                                     ->J->K->L
>>                                    /               \
>> A->B->C->D->H-I->M->N---------------->O
>>             \
>>              ->E->F-G->P(J)->Q(K)->R(L)
>>
>>
>> Hopefully that helps. :-)
>>
>> ---Brett.
>>
>>
>>
>> On Wed, Feb 1, 2012 at 9:56 AM, Stefan Frey<ste...@we...>  wrote:
>>> Frederick:
>>> My solution for this currently is to git cherry-pick the
>>> bug-fix commit into the 1.6.x branch.
>>>
>>> Usually bug fixes do not effect lots of file, and if there
>>> is a conflict it is usually easy to resolve.
>>>
>>> But the main reason for this solution is that usually I receive the
>>> bug-fixes as already merged into master.
>>>
>>> Should it not be possible to first rebase on master, then revert that
>>> rebase and then rebase on 1.6.x.?
>>>
>>> However I am curious if Brett has a better recommendation.
>>>
>>> Stefan
>>>
>>>
>>>
>>> On 02/01/2012 03:48 PM, Frederick Weld wrote:
>>>> Brett:
>>>> So what would be the git command sequence when wanting to create a fix
>>>> in a separate branch which is to be merged back to both 1.6.x and
>>>> master (You could copy-paste aforementioned order as a template)?
>>>>
>>>> If rebasing is done before merging into 1.6.x and master, the hotfix
>>>> commit will be altered (and not be the same as used in 1.6.x).
>>>> Probably no big issue as 1.6.x and master will never be merged again.
>>>>
>>>> --Frederick
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Keep Your Developer Skills Current with LearnDevNow!
>>>> The most comprehensive online learning library for Microsoft developers
>>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>>> http://p.sf.net/sfu/learndevnow-d2d
>>>> _______________________________________________
>>>> Rails-devel mailing list
>>>> Rai...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Keep Your Developer Skills Current with LearnDevNow!
>>> The most comprehensive online learning library for Microsoft developers
>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>> http://p.sf.net/sfu/learndevnow-d2d
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] git branching maintenance release (was; 1830 RSM Fix included)

[Stefan F. <ste...@we...>]

Brett:
I did test it and actually it works as I wished it work: It only takes 
the commits from feature after it branched from master and applies those
on top of the maintenance branch. And it does not add anything from 
those commits from the time between where maintenance branched until 
feature branched.

So the workflow for a hotfix is:

git checkout -b feature
... code & commit ...
git rebase master
git checkout master
git merge feature

followed by

git rebase --onto maintenance master feature
git checkout maintenance
git merge feature

How is this possible?
You are right that git only cares about node relationships, however with 
three arguments to rebase git can figure out what do:

Looking at the history of master and maintenance git knows that
the latter branched after D.
Looking at the history of master and feature git knows that the
latter branched after N.

Combining that information git knows that the commits between D and N
are actually not "new" part of feature.

Stefan


On 02/01/2012 06:55 PM, brett lentz wrote:
> The problem is all of the commits in between (The C->N commits). This
> is, admittedly, where my experience with git runs a little thin, so
> please feel free to test this out on your local repositories. (Hooray
> distributed SCM!)
>
> I *believe* what will happen if you rebase onto the maintenance
> branch, then merge after first having rebased onto master, will look
> something like this...
>
>
>                                          ->J->K->L
>                                         /               \
>    A->B->C->D->H->I->M->N---------------->O
>                \
>                 ->E->F-G--------------------------------------->P
>                              \                                       /.
>                               ->D->H->I->M->N->J->K->L
>
>
> Where P is another merge commit, just like O.
>
> Feel free to test this out and prove me right/wrong. :-) However, I'm
> pretty sure this is what will happen because git doesn't know or care
> about the context of the commits, but only cares about their
> parent/child relationships. So, once you've rebased your local branch
> onto the latest master, the parent commit of J *is* N, and so when you
> rebase onto the maintenance branch, it sees that the shared point C
> begins to diverge at D/E and, therefore from D to N is considered "new
> work" relative to the maintenance branch, exactly the same as the J to
> L commits that you really want on the maintenance branch.
>
> I think the way around this is to create *two* private feature
> branches, rebase one onto master and rebase the other onto the
> maintenance branch, and either merge or cherry-pick your commits
> between your two private feature branches in whatever way makes sense
> in your work flow.
>
> ---Brett.
>
>
>
> On Wed, Feb 1, 2012 at 12:37 PM, Stefan Frey<ste...@we...>  wrote:
>> Brett:
>> thanks for this excellent explanation.
>> So I got lucky that I have used a valid workflow from the beginning. And
>> indeed I applied the -x flag.
>>
>> However I am still wondering if it would be possible to "rebase back to
>> the past"?
>>
>>
>>                                       ->J->K->L
>>                                      /               \
>>   A->B->C->D->H-I->M->N---------------->O
>>               \
>>                ->E->F-G
>>
>> If I understand rebase correctly the command (assume that J to L is
>> branch feature, A to O to master and G to maintenance)
>>
>> rebase --onto maintenance master feature
>>
>> should end up with same result?
>>
>> A->B->C->D->H-I->M->N---------------->O
>>               \
>>                ->E->F-G->P(J)->Q(K)->R(L)
>>
>> Stefan
>>
>>
>>
>> On 02/01/2012 05:37 PM, brett lentz wrote:
>>> So...  there's a couple ways to do this, depending on what end-result we want.
>>>
>>> As Stefan mentions, cherry-picking is one of the better options for
>>> this. Changes should be merged into master, and then cherry-picked
>>> into the feature branch. Ideally, all cherry-picks should use the "-x"
>>> flag, which appends a line to your commit message saying where it was
>>> cherry-picked from. This is important because, otherwise, cherry-picks
>>> are commits that are wholly disconnected from their parent commit, so
>>> the chain of history is not well-preserved with cherry-picks.
>>>
>>> Remember, git cares about *history* far more than it does about any
>>> particular change. It tracks changes by parent-child relationships, so
>>> we need to be aware of when we're breaking that relationship.
>>>
>>> This is also what makes rebasing against two different branches
>>> somewhat problematic. Here's an example. (Hopefully my bad ascii art
>>> displays correctly on your side)
>>>
>>> Imagine commits in master look something like this:
>>>
>>> A ->    B ->    C ->    D
>>>
>>> Then, we create a release, and create a maintenance branch for the release:
>>>
>>> A->B->C->D->H-I
>>>              \
>>>               ->E->F-G
>>>
>>> Now, let's say more work is done, including some work I've done on a
>>> feature in my own local branch:
>>>
>>>                         ->J->K->L
>>>                        /
>>> A->B->C->D->H-I->M->N
>>>              \
>>>               ->E->F-G
>>>
>>>
>>> So...  now let's say I rebase my local branch against master. This
>>> rewinds my local branch to the common point in both branch's history
>>> (H), then replays the commits that were in master so my local branch
>>> "catches up", like so:
>>>
>>>                                      ->J->K->L
>>>                                     /
>>> A->B->C->D->H-I->M->N
>>>              \
>>>               ->E->F-G
>>>
>>> Git has reordered the history on my local branch. This is important
>>> because most traditional SCMs don't allow you to rewrite history. Git
>>> does, but it expects you to understand that this is what you're doing.
>>>
>>> This allows me to now merge my changes into master cleanly at the most
>>> current point in the history:
>>>
>>>                                      ->J->K->L
>>>                                     /               \
>>> A->B->C->D->H-I->M->N---------------->O
>>>              \
>>>               ->E->F-G
>>>
>>> Note, O is a merge commit that has no content of it's own, but marks
>>> the point in the history where there is multiple parents.
>>>
>>> So, now the question is... how do I get my changes into the maintenance branch?
>>>
>>> If I rebase my local tree a second time, git will again rewind to the
>>> common ancestor (C) and... it will see all of the new changes from
>>> master as if they were changes I had made in my local branch, because
>>> they are not common to the maintenance branch. This means that a bunch
>>> of stuff from master will be brought into the maintenance branch.
>>>
>>> Maybe that's what we want, and maybe it isn't.
>>>
>>> However, the alternative is to cherry-pick *only* my changes out of
>>> either master or my local branch, divorce them from the history, and
>>> append them into the maintenance branch, like so:
>>>
>>>
>>>                                      ->J->K->L
>>>                                     /               \
>>> A->B->C->D->H-I->M->N---------------->O
>>>              \
>>>               ->E->F-G->P(J)->Q(K)->R(L)
>>>
>>>
>>> Hopefully that helps. :-)
>>>
>>> ---Brett.
>>>
>>>
>>>
>>> On Wed, Feb 1, 2012 at 9:56 AM, Stefan Frey<ste...@we...>    wrote:
>>>> Frederick:
>>>> My solution for this currently is to git cherry-pick the
>>>> bug-fix commit into the 1.6.x branch.
>>>>
>>>> Usually bug fixes do not effect lots of file, and if there
>>>> is a conflict it is usually easy to resolve.
>>>>
>>>> But the main reason for this solution is that usually I receive the
>>>> bug-fixes as already merged into master.
>>>>
>>>> Should it not be possible to first rebase on master, then revert that
>>>> rebase and then rebase on 1.6.x.?
>>>>
>>>> However I am curious if Brett has a better recommendation.
>>>>
>>>> Stefan
>>>>
>>>>
>>>>
>>>> On 02/01/2012 03:48 PM, Frederick Weld wrote:
>>>>> Brett:
>>>>> So what would be the git command sequence when wanting to create a fix
>>>>> in a separate branch which is to be merged back to both 1.6.x and
>>>>> master (You could copy-paste aforementioned order as a template)?
>>>>>
>>>>> If rebasing is done before merging into 1.6.x and master, the hotfix
>>>>> commit will be altered (and not be the same as used in 1.6.x).
>>>>> Probably no big issue as 1.6.x and master will never be merged again.
>>>>>
>>>>> --Frederick
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Keep Your Developer Skills Current with LearnDevNow!
>>>>> The most comprehensive online learning library for Microsoft developers
>>>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>>>> http://p.sf.net/sfu/learndevnow-d2d
>>>>> _______________________________________________
>>>>> Rails-devel mailing list
>>>>> Rai...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Keep Your Developer Skills Current with LearnDevNow!
>>>> The most comprehensive online learning library for Microsoft developers
>>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>>> http://p.sf.net/sfu/learndevnow-d2d
>>>> _______________________________________________
>>>> Rails-devel mailing list
>>>> Rai...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Keep Your Developer Skills Current with LearnDevNow!
>>> The most comprehensive online learning library for Microsoft developers
>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>> http://p.sf.net/sfu/learndevnow-d2d
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] git branching maintenance release (was; 1830 RSM Fix included)

[brett l. <bre...@gm...>]

Awesome. I'm actually happy to be wrong on this. It's nice to see that
git is smart enough to not bring in unrelated changes.

Thanks for testing this. :-)

---Brett.



On Wed, Feb 1, 2012 at 1:47 PM, Stefan Frey <ste...@we...> wrote:
> Brett:
> I did test it and actually it works as I wished it work: It only takes
> the commits from feature after it branched from master and applies those
> on top of the maintenance branch. And it does not add anything from
> those commits from the time between where maintenance branched until
> feature branched.
>
> So the workflow for a hotfix is:
>
> git checkout -b feature
> ... code & commit ...
> git rebase master
> git checkout master
> git merge feature
>
> followed by
>
> git rebase --onto maintenance master feature
> git checkout maintenance
> git merge feature
>
> How is this possible?
> You are right that git only cares about node relationships, however with
> three arguments to rebase git can figure out what do:
>
> Looking at the history of master and maintenance git knows that
> the latter branched after D.
> Looking at the history of master and feature git knows that the
> latter branched after N.
>
> Combining that information git knows that the commits between D and N
> are actually not "new" part of feature.
>
> Stefan
>
>
> On 02/01/2012 06:55 PM, brett lentz wrote:
>> The problem is all of the commits in between (The C->N commits). This
>> is, admittedly, where my experience with git runs a little thin, so
>> please feel free to test this out on your local repositories. (Hooray
>> distributed SCM!)
>>
>> I *believe* what will happen if you rebase onto the maintenance
>> branch, then merge after first having rebased onto master, will look
>> something like this...
>>
>>
>>                                          ->J->K->L
>>                                         /               \
>>    A->B->C->D->H->I->M->N---------------->O
>>                \
>>                 ->E->F-G--------------------------------------->P
>>                              \                                       /.
>>                               ->D->H->I->M->N->J->K->L
>>
>>
>> Where P is another merge commit, just like O.
>>
>> Feel free to test this out and prove me right/wrong. :-) However, I'm
>> pretty sure this is what will happen because git doesn't know or care
>> about the context of the commits, but only cares about their
>> parent/child relationships. So, once you've rebased your local branch
>> onto the latest master, the parent commit of J *is* N, and so when you
>> rebase onto the maintenance branch, it sees that the shared point C
>> begins to diverge at D/E and, therefore from D to N is considered "new
>> work" relative to the maintenance branch, exactly the same as the J to
>> L commits that you really want on the maintenance branch.
>>
>> I think the way around this is to create *two* private feature
>> branches, rebase one onto master and rebase the other onto the
>> maintenance branch, and either merge or cherry-pick your commits
>> between your two private feature branches in whatever way makes sense
>> in your work flow.
>>
>> ---Brett.
>>
>>
>>
>> On Wed, Feb 1, 2012 at 12:37 PM, Stefan Frey<ste...@we...>  wrote:
>>> Brett:
>>> thanks for this excellent explanation.
>>> So I got lucky that I have used a valid workflow from the beginning. And
>>> indeed I applied the -x flag.
>>>
>>> However I am still wondering if it would be possible to "rebase back to
>>> the past"?
>>>
>>>
>>>                                       ->J->K->L
>>>                                      /               \
>>>   A->B->C->D->H-I->M->N---------------->O
>>>               \
>>>                ->E->F-G
>>>
>>> If I understand rebase correctly the command (assume that J to L is
>>> branch feature, A to O to master and G to maintenance)
>>>
>>> rebase --onto maintenance master feature
>>>
>>> should end up with same result?
>>>
>>> A->B->C->D->H-I->M->N---------------->O
>>>               \
>>>                ->E->F-G->P(J)->Q(K)->R(L)
>>>
>>> Stefan
>>>
>>>
>>>
>>> On 02/01/2012 05:37 PM, brett lentz wrote:
>>>> So...  there's a couple ways to do this, depending on what end-result we want.
>>>>
>>>> As Stefan mentions, cherry-picking is one of the better options for
>>>> this. Changes should be merged into master, and then cherry-picked
>>>> into the feature branch. Ideally, all cherry-picks should use the "-x"
>>>> flag, which appends a line to your commit message saying where it was
>>>> cherry-picked from. This is important because, otherwise, cherry-picks
>>>> are commits that are wholly disconnected from their parent commit, so
>>>> the chain of history is not well-preserved with cherry-picks.
>>>>
>>>> Remember, git cares about *history* far more than it does about any
>>>> particular change. It tracks changes by parent-child relationships, so
>>>> we need to be aware of when we're breaking that relationship.
>>>>
>>>> This is also what makes rebasing against two different branches
>>>> somewhat problematic. Here's an example. (Hopefully my bad ascii art
>>>> displays correctly on your side)
>>>>
>>>> Imagine commits in master look something like this:
>>>>
>>>> A ->    B ->    C ->    D
>>>>
>>>> Then, we create a release, and create a maintenance branch for the release:
>>>>
>>>> A->B->C->D->H-I
>>>>              \
>>>>               ->E->F-G
>>>>
>>>> Now, let's say more work is done, including some work I've done on a
>>>> feature in my own local branch:
>>>>
>>>>                         ->J->K->L
>>>>                        /
>>>> A->B->C->D->H-I->M->N
>>>>              \
>>>>               ->E->F-G
>>>>
>>>>
>>>> So...  now let's say I rebase my local branch against master. This
>>>> rewinds my local branch to the common point in both branch's history
>>>> (H), then replays the commits that were in master so my local branch
>>>> "catches up", like so:
>>>>
>>>>                                      ->J->K->L
>>>>                                     /
>>>> A->B->C->D->H-I->M->N
>>>>              \
>>>>               ->E->F-G
>>>>
>>>> Git has reordered the history on my local branch. This is important
>>>> because most traditional SCMs don't allow you to rewrite history. Git
>>>> does, but it expects you to understand that this is what you're doing.
>>>>
>>>> This allows me to now merge my changes into master cleanly at the most
>>>> current point in the history:
>>>>
>>>>                                      ->J->K->L
>>>>                                     /               \
>>>> A->B->C->D->H-I->M->N---------------->O
>>>>              \
>>>>               ->E->F-G
>>>>
>>>> Note, O is a merge commit that has no content of it's own, but marks
>>>> the point in the history where there is multiple parents.
>>>>
>>>> So, now the question is... how do I get my changes into the maintenance branch?
>>>>
>>>> If I rebase my local tree a second time, git will again rewind to the
>>>> common ancestor (C) and... it will see all of the new changes from
>>>> master as if they were changes I had made in my local branch, because
>>>> they are not common to the maintenance branch. This means that a bunch
>>>> of stuff from master will be brought into the maintenance branch.
>>>>
>>>> Maybe that's what we want, and maybe it isn't.
>>>>
>>>> However, the alternative is to cherry-pick *only* my changes out of
>>>> either master or my local branch, divorce them from the history, and
>>>> append them into the maintenance branch, like so:
>>>>
>>>>
>>>>                                      ->J->K->L
>>>>                                     /               \
>>>> A->B->C->D->H-I->M->N---------------->O
>>>>              \
>>>>               ->E->F-G->P(J)->Q(K)->R(L)
>>>>
>>>>
>>>> Hopefully that helps. :-)
>>>>
>>>> ---Brett.
>>>>
>>>>
>>>>
>>>> On Wed, Feb 1, 2012 at 9:56 AM, Stefan Frey<ste...@we...>    wrote:
>>>>> Frederick:
>>>>> My solution for this currently is to git cherry-pick the
>>>>> bug-fix commit into the 1.6.x branch.
>>>>>
>>>>> Usually bug fixes do not effect lots of file, and if there
>>>>> is a conflict it is usually easy to resolve.
>>>>>
>>>>> But the main reason for this solution is that usually I receive the
>>>>> bug-fixes as already merged into master.
>>>>>
>>>>> Should it not be possible to first rebase on master, then revert that
>>>>> rebase and then rebase on 1.6.x.?
>>>>>
>>>>> However I am curious if Brett has a better recommendation.
>>>>>
>>>>> Stefan
>>>>>
>>>>>
>>>>>
>>>>> On 02/01/2012 03:48 PM, Frederick Weld wrote:
>>>>>> Brett:
>>>>>> So what would be the git command sequence when wanting to create a fix
>>>>>> in a separate branch which is to be merged back to both 1.6.x and
>>>>>> master (You could copy-paste aforementioned order as a template)?
>>>>>>
>>>>>> If rebasing is done before merging into 1.6.x and master, the hotfix
>>>>>> commit will be altered (and not be the same as used in 1.6.x).
>>>>>> Probably no big issue as 1.6.x and master will never be merged again.
>>>>>>
>>>>>> --Frederick
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Keep Your Developer Skills Current with LearnDevNow!
>>>>>> The most comprehensive online learning library for Microsoft developers
>>>>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>>>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>>>>> http://p.sf.net/sfu/learndevnow-d2d
>>>>>> _______________________________________________
>>>>>> Rails-devel mailing list
>>>>>> Rai...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Keep Your Developer Skills Current with LearnDevNow!
>>>>> The most comprehensive online learning library for Microsoft developers
>>>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>>>> http://p.sf.net/sfu/learndevnow-d2d
>>>>> _______________________________________________
>>>>> Rails-devel mailing list
>>>>> Rai...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Keep Your Developer Skills Current with LearnDevNow!
>>>> The most comprehensive online learning library for Microsoft developers
>>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>>> http://p.sf.net/sfu/learndevnow-d2d
>>>> _______________________________________________
>>>> Rails-devel mailing list
>>>> Rai...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Keep Your Developer Skills Current with LearnDevNow!
>>> The most comprehensive online learning library for Microsoft developers
>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>> http://p.sf.net/sfu/learndevnow-d2d
>>> _______________________________________________
>>> Rails-devel mailing list
>>> Rai...@li...
>>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> Rails-devel mailing list
>> Rai...@li...
>> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included

[Stefan F. <ste...@we...>]

Erik:
the patch works perfectly: However you the commit you used
to fix it is tainted by your merge:

If you check a26c986 it changes 15 files and contains many
changes which where actually from Frederick.

My guess it that is somehow related to the fact that you merge
your changes instead of using rebase to add them at the end of the 
repository?

Have you set the git config branch.autosetuprebase=always?
This was recommended by Brett Lentz and avoids the frequent merges
you have used recently.

For current case I will recreate a commit which only contains your fix 
for the 1.6.x branch.

Stefan

On 01/31/2012 10:25 PM, Erik Vos wrote:
> I just have pushed a different fix: two statements had to be swapped.
>
> Martin, your fix would only allow selling 20%, but in fact the president can also sell only 10% if he wants.
>
> Erik.
>
> From: Dr....@t-... [mailto:Dr....@t-...]
> Sent: Tuesday, January 31, 2012 9:15 PM
> To: Development list for Rails: an 18xx game; Erik Vos; Stefan Frey
> Subject: Re: [Rails-devel] Fwd: 1830 RSM Fix included
>
> Hi Stefan&Erik,
> i believe the following small fix solves that problem,
> Please run your usual test scenarios :) And maybe we should add that save file as a test !
> Regards,
> Martin
> diff --git a/rails/game/StockRound.java b/rails/game/StockRound.java
> index 037d2cc..25d05ce 100644
> --- a/rails/game/StockRound.java
> +++ b/rails/game/StockRound.java
> @@ -464,7 +464,7 @@
>                */
>               // Take care for max. 4 share units per share
>               compName = company.getName();
> -            int[] shareCountPerUnit = playerPortfolio.getCertificateTypeCountsPerCompany(compName, false);
> +            int[] shareCountPerUnit = playerPortfolio.getCertificateTypeCountsPerCompany(compName, true);//Martin: we need to make sure we find the president only share to sell in the next step!
>               // Check the price. If a cert was sold before this turn, the original price is still valid.
>               price = getCurrentSellPrice(company);
>
> Von: Stefan Frey<ste...@we...>
> An: Erik Vos<eri...@xs...>
> Cc: an 18xx game<rai...@li...>
> Betreff: [Rails-devel] Fwd: 1830 RSM
> Datum: Tue, 31 Jan 2012 16:15:26 +0100
> Erik:
> I forward you a report of a potentially critical bug: It does not allow
> selling the director of the NYNH given that the operating director owns
> the president share only and 2 other players have 20% each and Pool
> having 30% only.
>
> This bug can be reproduced back to 1.5.3, unfortunately the save file is
> not fully loadable under 1.5.2.
>
> I suspect this is related to the changes for 1835 at that time, I have
> to admit that I cannot fully understand the code used to create the
> actions for selling, so you might be in a better position to find this bug.
>
> Thanks,
> Stefan
>
>
> -------- Original Message --------
> Subject: Fwd: 1830 RSM
> Date: Tue, 31 Jan 2012 09:30:48 -0500
> From: Bob Probst
> To: stefan.frey
>
> Stefan, a friend of mine found this issue. I haven't confirmed it yet
> but he's pretty thorough.
>
> I'm sure you can contact him directly if you have any questions
>
>
> ---------- Forwarded message ----------
> From: "Ing. Antonio Baracca"
> Date: Tue, 31 Jan 2012 14:53:37 +0100
> Subject: Fwd: 1830 RSM
> To: Bob Probst
> Cc: Palmiro Matteini
>
> Hi Bob,
> we have found a major bug on the 1830 module.
> The current player cannot sell 10% of NYNH from his president
> certificate (remaining so with only 10% of NYNH and shifting the
> presidency of the corporation).
> I attach a saved file of the current 1830 game with the bug point.
> I have seen you are currently in contact with programmers.
> Can you please report to them this bug?
> Thank you in advance.
> Regards
> Antonio
>
>
>
> Inizio messaggio inoltrato:
>
>> Da: "Palmiro Matteini"
>> Data: 31 gennaio 2012 14.23.26 GMT+01.00
>> A: "Ing. Antonio Baracca"
>> Oggetto: Re: 1830 RSM
>>
>> Eccolo.
>> Ciao.
>>
>> Palmiro Matteini
>> pma...@om...
>> ----- Original Message -----
>> From: Ing. Antonio Baracca
>> To: Palmiro Matteini
>> Sent: Tuesday, January 31, 2012 11:46 AM
>> Subject: Re: 1830 RSM
>>
>> Mandami la salvata che ci guardo
>>
>>
>> Antonio Baracca
>> ant...@ti...
>>
>> Il giorno 31/gen/2012, alle ore 09:28, "Palmiro Matteini" ha scritto:
>>
>>> Ciao Antonio.
>>> Nella partita che stiamo facendo con Rail in ASGS, è successa una cosa strana.
>>> Glauco ha venduto azioni della NYNH tenendosi solo il certificato della presidenza del 20%.
>>> Al giro successivo c'erano altri giocatori che avevano il 20% e nel bank pool c'era il 30%.
>>> Il programma stranamente non gli ha permesso di vendere il certificato della presidenza.
>>> C'è un buco nel programma ?
>>> Ciao.
>>>
>>> Palmiro Matteini
>>> pma...@om...
>
> Antonio Baracca
> ant...@gm...
>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included

[<Dr....@t-...>]

Hi Stefan & Erik, 

	i dont see the fixes in 1.6.x just in master ? Is that correct and
intended ? 

	Regards, 

	Martin  

	  Von: Stefan Frey <ste...@we...>
 An: rai...@li...
 Betreff: Re: [Rails-devel] FW:  Fwd: 1830 RSM Fix included
 Datum: Wed, 01 Feb 2012 08:08:14 +0100

 Erik:
 the patch works perfectly: However you the commit you used
 to fix it is tainted by your merge:

 If you check a26c986 it changes 15 files and contains many
 changes which where actually from Frederick.

 My guess it that is somehow related to the fact that you merge
 your changes instead of using rebase to add them at the end of the 
 repository?

 Have you set the git config branch.autosetuprebase=always?
 This was recommended by Brett Lentz and avoids the frequent merges
 you have used recently.

 For current case I will recreate a commit which only contains your
fix 
 for the 1.6.x branch.

 Stefan

 On 01/31/2012 10:25 PM, Erik Vos wrote:
 > I just have pushed a different fix: two statements had to be
swapped.
 >
 > Martin, your fix would only allow selling 20%, but in fact the
president can also sell only 10% if he wants.
 >
 > Erik.
 >
 > From: Dr....@t-...
[mailto:Dr....@t-...]
 > Sent: Tuesday, January 31, 2012 9:15 PM
 > To: Development list for Rails: an 18xx game; Erik Vos; Stefan Frey
 > Subject: Re: [Rails-devel] Fwd: 1830 RSM Fix included
 >
 > Hi Stefan&Erik,
 > i believe the following small fix solves that problem,
 > Please run your usual test scenarios :) And maybe we should add
that save file as a test !
 > Regards,
 > Martin
 > diff --git a/rails/game/StockRound.java
b/rails/game/StockRound.java
 > index 037d2cc..25d05ce 100644
 > --- a/rails/game/StockRound.java
 > +++ b/rails/game/StockRound.java
 > @@ -464,7 +464,7 @@
 >                */
 >               // Take care for max. 4 share units per share
 >               compName = company.getName();
 > -            int[] shareCountPerUnit =
playerPortfolio.getCertificateTypeCountsPerCompany(compName, false);
 > +            int[] shareCountPerUnit =
playerPortfolio.getCertificateTypeCountsPerCompany(compName,
true);//Martin: we need to make sure we find the president only share
to sell in the next step!
 >               // Check the price. If a cert was sold before this
turn, the original price is still valid.
 >               price = getCurrentSellPrice(company);
 >
 > Von: Stefan Frey
 > An: Erik Vos
 > Cc: an 18xx game
 > Betreff: [Rails-devel] Fwd: 1830 RSM
 > Datum: Tue, 31 Jan 2012 16:15:26 +0100
 > Erik:
 > I forward you a report of a potentially critical bug: It does not
allow
 > selling the director of the NYNH given that the operating director
owns
 > the president share only and 2 other players have 20% each and Pool
 > having 30% only.
 >
 > This bug can be reproduced back to 1.5.3, unfortunately the save
file is
 > not fully loadable under 1.5.2.
 >
 > I suspect this is related to the changes for 1835 at that time, I
have
 > to admit that I cannot fully understand the code used to create the
 > actions for selling, so you might be in a better position to find
this bug.
 >
 > Thanks,
 > Stefan
 >
 >
 > -------- Original Message --------
 > Subject: Fwd: 1830 RSM
 > Date: Tue, 31 Jan 2012 09:30:48 -0500
 > From: Bob Probst
 > To: stefan.frey
 >
 > Stefan, a friend of mine found this issue. I haven't confirmed it
yet
 > but he's pretty thorough.
 >
 > I'm sure you can contact him directly if you have any questions
 >
 >
 > ---------- Forwarded message ----------
 > From: "Ing. Antonio Baracca"
 > Date: Tue, 31 Jan 2012 14:53:37 +0100
 > Subject: Fwd: 1830 RSM
 > To: Bob Probst
 > Cc: Palmiro Matteini
 >
 > Hi Bob,
 > we have found a major bug on the 1830 module.
 > The current player cannot sell 10% of NYNH from his president
 > certificate (remaining so with only 10% of NYNH and shifting the
 > presidency of the corporation).
 > I attach a saved file of the current 1830 game with the bug point.
 > I have seen you are currently in contact with programmers.
 > Can you please report to them this bug?
 > Thank you in advance.
 > Regards
 > Antonio
 >
 >
 >
 > Inizio messaggio inoltrato:
 >
 >> Da: "Palmiro Matteini"
 >> Data: 31 gennaio 2012 14.23.26 GMT+01.00
 >> A: "Ing. Antonio Baracca"
 >> Oggetto: Re: 1830 RSM
 >>
 >> Eccolo.
 >> Ciao.
 >>
 >> Palmiro Matteini
 >> pma...@om...
 >> ----- Original Message -----
 >> From: Ing. Antonio Baracca
 >> To: Palmiro Matteini
 >> Sent: Tuesday, January 31, 2012 11:46 AM
 >> Subject: Re: 1830 RSM
 >>
 >> Mandami la salvata che ci guardo
 >>
 >>
 >> Antonio Baracca
 >> ant...@ti...
 >>
 >> Il giorno 31/gen/2012, alle ore 09:28, "Palmiro Matteini" ha
scritto:
 >>
 >>> Ciao Antonio.
 >>> Nella partita che stiamo facendo con Rail in ASGS, è successa
una cosa strana.
 >>> Glauco ha venduto azioni della NYNH tenendosi solo il certificato
della presidenza del 20%.
 >>> Al giro successivo c'erano altri giocatori che avevano il 20% e
nel bank pool c'era il 30%.
 >>> Il programma stranamente non gli ha permesso di vendere il
certificato della presidenza.
 >>> C'è un buco nel programma ?
 >>> Ciao.
 >>>
 >>> Palmiro Matteini
 >>> pma...@om...
 >
 > Antonio Baracca
 > ant...@gm...
 >
 >
 >
 >
------------------------------------------------------------------------------
 > Keep Your Developer Skills Current with LearnDevNow!
 > The most comprehensive online learning library for Microsoft
developers
 > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
MVC3,
 > Metro Style Apps, more. Free future releases when you subscribe
now!
 > http://p.sf.net/sfu/learndevnow-d2d
 > _______________________________________________
 > Rails-devel mailing list
 > Rai...@li...
 > https://lists.sourceforge.net/lists/listinfo/rails-devel

 ------------------------------------------------------------------------------
 Keep Your Developer Skills Current with LearnDevNow!
 The most comprehensive online learning library for Microsoft
developers
 is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3,
MVC3,
 Metro Style Apps, more. Free future releases when you subscribe now!
 http://p.sf.net/sfu/learndevnow-d2d
 _______________________________________________
 Rails-devel mailing list
 Rai...@li...
 https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included

[Erik V. <eri...@xs...>]

Sorry, I had wanted but forgot to add that I’m only working with master.

 

Erik.

 

From: Dr....@t-... [mailto:Dr....@t-...] 
Sent: Wednesday, February 01, 2012 8:18 AM
To: Development list for Rails: an 18xx game
Subject: Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included

 

Hi Stefan & Erik,

 

i dont see the fixes in 1.6.x just in master ? Is that correct and intended ?

 

Regards,

Martin

 

Von: Stefan Frey <ste...@we...>
An: rai...@li...
Betreff: Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included
Datum: Wed, 01 Feb 2012 08:08:14 +0100

Erik:
the patch works perfectly: However you the commit you used
to fix it is tainted by your merge:

If you check a26c986 it changes 15 files and contains many
changes which where actually from Frederick.

My guess it that is somehow related to the fact that you merge
your changes instead of using rebase to add them at the end of the 
repository?

Have you set the git config branch.autosetuprebase=always?
This was recommended by Brett Lentz and avoids the frequent merges
you have used recently.

For current case I will recreate a commit which only contains your fix 
for the 1.6.x branch.

Stefan

On 01/31/2012 10:25 PM, Erik Vos wrote:
> I just have pushed a different fix: two statements had to be swapped.
>
> Martin, your fix would only allow selling 20%, but in fact the president can also sell only 10% if he wants.
>
> Erik.
>
> From: Dr....@t-... [mailto:Dr....@t-...]
> Sent: Tuesday, January 31, 2012 9:15 PM
> To: Development list for Rails: an 18xx game; Erik Vos; Stefan Frey
> Subject: Re: [Rails-devel] Fwd: 1830 RSM Fix included
>
> Hi Stefan&Erik,
> i believe the following small fix solves that problem,
> Please run your usual test scenarios :) And maybe we should add that save file as a test !
> Regards,
> Martin
> diff --git a/rails/game/StockRound.java b/rails/game/StockRound.java
> index 037d2cc..25d05ce 100644
> --- a/rails/game/StockRound.java
> +++ b/rails/game/StockRound.java
> @@ -464,7 +464,7 @@
> */
> // Take care for max. 4 share units per share
> compName = company.getName();
> - int[] shareCountPerUnit = playerPortfolio.getCertificateTypeCountsPerCompany(compName, false);
> + int[] shareCountPerUnit = playerPortfolio.getCertificateTypeCountsPerCompany(compName, true);//Martin: we need to make sure we find the president only share to sell in the next step!
> // Check the price. If a cert was sold before this turn, the original price is still valid.
> price = getCurrentSellPrice(company);
>
> Von: Stefan Frey
> An: Erik Vos
> Cc: an 18xx game
> Betreff: [Rails-devel] Fwd: 1830 RSM
> Datum: Tue, 31 Jan 2012 16:15:26 +0100
> Erik:
> I forward you a report of a potentially critical bug: It does not allow
> selling the director of the NYNH given that the operating director owns
> the president share only and 2 other players have 20% each and Pool
> having 30% only.
>
> This bug can be reproduced back to 1.5.3, unfortunately the save file is
> not fully loadable under 1.5.2.
>
> I suspect this is related to the changes for 1835 at that time, I have
> to admit that I cannot fully understand the code used to create the
> actions for selling, so you might be in a better position to find this bug.
>
> Thanks,
> Stefan
>
>
> -------- Original Message --------
> Subject: Fwd: 1830 RSM
> Date: Tue, 31 Jan 2012 09:30:48 -0500
> From: Bob Probst
> To: stefan.frey
>
> Stefan, a friend of mine found this issue. I haven't confirmed it yet
> but he's pretty thorough.
>
> I'm sure you can contact him directly if you have any questions
>
>
> ---------- Forwarded message ----------
> From: "Ing. Antonio Baracca"
> Date: Tue, 31 Jan 2012 14:53:37 +0100
> Subject: Fwd: 1830 RSM
> To: Bob Probst
> Cc: Palmiro Matteini
>
> Hi Bob,
> we have found a major bug on the 1830 module.
> The current player cannot sell 10% of NYNH from his president
> certificate (remaining so with only 10% of NYNH and shifting the
> presidency of the corporation).
> I attach a saved file of the current 1830 game with the bug point.
> I have seen you are currently in contact with programmers.
> Can you please report to them this bug?
> Thank you in advance.
> Regards
> Antonio
>
>
>
> Inizio messaggio inoltrato:
>
>> Da: "Palmiro Matteini"
>> Data: 31 gennaio 2012 14.23.26 GMT+01.00
>> A: "Ing. Antonio Baracca"
>> Oggetto: Re: 1830 RSM
>>
>> Eccolo.
>> Ciao.
>>
>> Palmiro Matteini
>> pma...@om...
>> ----- Original Message -----
>> From: Ing. Antonio Baracca
>> To: Palmiro Matteini
>> Sent: Tuesday, January 31, 2012 11:46 AM
>> Subject: Re: 1830 RSM
>>
>> Mandami la salvata che ci guardo
>>
>>
>> Antonio Baracca
>> ant...@ti...
>>
>> Il giorno 31/gen/2012, alle ore 09:28, "Palmiro Matteini" ha scritto:
>>
>>> Ciao Antonio.
>>> Nella partita che stiamo facendo con Rail in ASGS, è successa una cosa strana.
>>> Glauco ha venduto azioni della NYNH tenendosi solo il certificato della presidenza del 20%.
>>> Al giro successivo c'erano altri giocatori che avevano il 20% e nel bank pool c'era il 30%.
>>> Il programma stranamente non gli ha permesso di vendere il certificato della presidenza.
>>> C'è un buco nel programma ?
>>> Ciao.
>>>
>>> Palmiro Matteini
>>> pma...@om...
>
> Antonio Baracca
> ant...@gm...
>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel


------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Rails-devel mailing list
Rai...@li...
https://lists.sourceforge.net/lists/listinfo/rails-devel

 

Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included

[Stefan F. <ste...@we...>]

Martin:
Sorry did not push the fix, waited for the new release to be complete.
Stefan

On 02/01/2012 08:18 AM, Dr....@t-... wrote:
> Hi Stefan & Erik,
>
> i dont see the fixes in 1.6.x just in master ? Is that correct and
> intended ?
>
> Regards,
>
> Martin
>
> *Von:* Stefan Frey <ste...@we...>
> *An:* rai...@li...
> *Betreff:* Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included
> *Datum:* Wed, 01 Feb 2012 08:08:14 +0100
>
> Erik:
> the patch works perfectly: However you the commit you used
> to fix it is tainted by your merge:
>
> If you check a26c986 it changes 15 files and contains many
> changes which where actually from Frederick.
>
> My guess it that is somehow related to the fact that you merge
> your changes instead of using rebase to add them at the end of the
> repository?
>
> Have you set the git config branch.autosetuprebase=always?
> This was recommended by Brett Lentz and avoids the frequent merges
> you have used recently.
>
> For current case I will recreate a commit which only contains your fix
> for the 1.6.x branch.
>
> Stefan
>
> On 01/31/2012 10:25 PM, Erik Vos wrote:
>  > I just have pushed a different fix: two statements had to be swapped.
>  >
>  > Martin, your fix would only allow selling 20%, but in fact the
> president can also sell only 10% if he wants.
>  >
>  > Erik.
>  >
>  > From: Dr....@t-... [mailto:Dr....@t-...]
>  > Sent: Tuesday, January 31, 2012 9:15 PM
>  > To: Development list for Rails: an 18xx game; Erik Vos; Stefan Frey
>  > Subject: Re: [Rails-devel] Fwd: 1830 RSM Fix included
>  >
>  > Hi Stefan&Erik,
>  > i believe the following small fix solves that problem,
>  > Please run your usual test scenarios :) And maybe we should add that
> save file as a test !
>  > Regards,
>  > Martin
>  > diff --git a/rails/game/StockRound.java b/rails/game/StockRound.java
>  > index 037d2cc..25d05ce 100644
>  > --- a/rails/game/StockRound.java
>  > +++ b/rails/game/StockRound.java
>  > @@ -464,7 +464,7 @@
>  > */
>  > // Take care for max. 4 share units per share
>  > compName = company.getName();
>  > - int[] shareCountPerUnit =
> playerPortfolio.getCertificateTypeCountsPerCompany(compName, false);
>  > + int[] shareCountPerUnit =
> playerPortfolio.getCertificateTypeCountsPerCompany(compName,
> true);//Martin: we need to make sure we find the president only share to
> sell in the next step!
>  > // Check the price. If a cert was sold before this turn, the original
> price is still valid.
>  > price = getCurrentSellPrice(company);
>  >
>  > Von: Stefan Frey
>  > An: Erik Vos
>  > Cc: an 18xx game
>  > Betreff: [Rails-devel] Fwd: 1830 RSM
>  > Datum: Tue, 31 Jan 2012 16:15:26 +0100
>  > Erik:
>  > I forward you a report of a potentially critical bug: It does not allow
>  > selling the director of the NYNH given that the operating director owns
>  > the president share only and 2 other players have 20% each and Pool
>  > having 30% only.
>  >
>  > This bug can be reproduced back to 1.5.3, unfortunately the save file is
>  > not fully loadable under 1.5.2.
>  >
>  > I suspect this is related to the changes for 1835 at that time, I have
>  > to admit that I cannot fully understand the code used to create the
>  > actions for selling, so you might be in a better position to find
> this bug.
>  >
>  > Thanks,
>  > Stefan
>  >
>  >
>  > -------- Original Message --------
>  > Subject: Fwd: 1830 RSM
>  > Date: Tue, 31 Jan 2012 09:30:48 -0500
>  > From: Bob Probst
>  > To: stefan.frey
>  >
>  > Stefan, a friend of mine found this issue. I haven't confirmed it yet
>  > but he's pretty thorough.
>  >
>  > I'm sure you can contact him directly if you have any questions
>  >
>  >
>  > ---------- Forwarded message ----------
>  > From: "Ing. Antonio Baracca"
>  > Date: Tue, 31 Jan 2012 14:53:37 +0100
>  > Subject: Fwd: 1830 RSM
>  > To: Bob Probst
>  > Cc: Palmiro Matteini
>  >
>  > Hi Bob,
>  > we have found a major bug on the 1830 module.
>  > The current player cannot sell 10% of NYNH from his president
>  > certificate (remaining so with only 10% of NYNH and shifting the
>  > presidency of the corporation).
>  > I attach a saved file of the current 1830 game with the bug point.
>  > I have seen you are currently in contact with programmers.
>  > Can you please report to them this bug?
>  > Thank you in advance.
>  > Regards
>  > Antonio
>  >
>  >
>  >
>  > Inizio messaggio inoltrato:
>  >
>  >> Da: "Palmiro Matteini"
>  >> Data: 31 gennaio 2012 14.23.26 GMT+01.00
>  >> A: "Ing. Antonio Baracca"
>  >> Oggetto: Re: 1830 RSM
>  >>
>  >> Eccolo.
>  >> Ciao.
>  >>
>  >> Palmiro Matteini
>  >> pma...@om...
>  >> ----- Original Message -----
>  >> From: Ing. Antonio Baracca
>  >> To: Palmiro Matteini
>  >> Sent: Tuesday, January 31, 2012 11:46 AM
>  >> Subject: Re: 1830 RSM
>  >>
>  >> Mandami la salvata che ci guardo
>  >>
>  >>
>  >> Antonio Baracca
>  >> ant...@ti...
>  >>
>  >> Il giorno 31/gen/2012, alle ore 09:28, "Palmiro Matteini" ha scritto:
>  >>
>  >>> Ciao Antonio.
>  >>> Nella partita che stiamo facendo con Rail in ASGS, è successa una
> cosa strana.
>  >>> Glauco ha venduto azioni della NYNH tenendosi solo il certificato
> della presidenza del 20%.
>  >>> Al giro successivo c'erano altri giocatori che avevano il 20% e nel
> bank pool c'era il 30%.
>  >>> Il programma stranamente non gli ha permesso di vendere il
> certificato della presidenza.
>  >>> C'è un buco nel programma ?
>  >>> Ciao.
>  >>>
>  >>> Palmiro Matteini
>  >>> pma...@om...
>  >
>  > Antonio Baracca
>  > ant...@gm...
>  >
>  >
>  >
>  >
> ------------------------------------------------------------------------------
>  > Keep Your Developer Skills Current with LearnDevNow!
>  > The most comprehensive online learning library for Microsoft developers
>  > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>  > Metro Style Apps, more. Free future releases when you subscribe now!
>  > http://p.sf.net/sfu/learndevnow-d2d
>  > _______________________________________________
>  > Rails-devel mailing list
>  > Rai...@li...
>  > https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel
>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
>
>
>
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel

Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included

[Erik V. <eri...@xs...>]

Stefan,

As I explained before:  I had accidentally pulled [from master] while checked out in my local nonmodal branch, which had some unmerged commits.  The merge occurred when I was rebasing everything back in order.
If you know a way to protect myself against such mistakes, please tell me.  I don't know if autosetuprebase will fix that, but I have added it anyway.

BTW my git pull and push are set up for master only.  I'm keeping all other remote branches out of the way.

Erik.

> -----Original Message-----
> From: Stefan Frey [mailto:ste...@we...]
> Sent: Wednesday, February 01, 2012 8:08 AM
> To: rai...@li...
> Subject: Re: [Rails-devel] FW: Fwd: 1830 RSM Fix included
> 
> Erik:
> the patch works perfectly: However you the commit you used to fix it is
> tainted by your merge:
> 
> If you check a26c986 it changes 15 files and contains many changes which
> where actually from Frederick.
> 
> My guess it that is somehow related to the fact that you merge your changes
> instead of using rebase to add them at the end of the repository?
> 
> Have you set the git config branch.autosetuprebase=always?
> This was recommended by Brett Lentz and avoids the frequent merges you
> have used recently.
> 
> For current case I will recreate a commit which only contains your fix for the
> 1.6.x branch.
> 
> Stefan
> 
> On 01/31/2012 10:25 PM, Erik Vos wrote:
> > I just have pushed a different fix: two statements had to be swapped.
> >
> > Martin, your fix would only allow selling 20%, but in fact the president can
> also sell only 10% if he wants.
> >
> > Erik.
> >
> > From: Dr....@t-... [mailto:Dr.Martin.Brumm@t-
> online.de]
> > Sent: Tuesday, January 31, 2012 9:15 PM
> > To: Development list for Rails: an 18xx game; Erik Vos; Stefan Frey
> > Subject: Re: [Rails-devel] Fwd: 1830 RSM Fix included
> >
> > Hi Stefan&Erik,
> > i believe the following small fix solves that problem, Please run your
> > usual test scenarios :) And maybe we should add that save file as a test !
> > Regards,
> > Martin
> > diff --git a/rails/game/StockRound.java b/rails/game/StockRound.java
> > index 037d2cc..25d05ce 100644
> > --- a/rails/game/StockRound.java
> > +++ b/rails/game/StockRound.java
> > @@ -464,7 +464,7 @@
> >                */
> >               // Take care for max. 4 share units per share
> >               compName = company.getName();
> > -            int[] shareCountPerUnit =
> playerPortfolio.getCertificateTypeCountsPerCompany(compName, false);
> > +            int[] shareCountPerUnit =
> playerPortfolio.getCertificateTypeCountsPerCompany(compName,
> true);//Martin: we need to make sure we find the president only share to
> sell in the next step!
> >               // Check the price. If a cert was sold before this turn, the original
> price is still valid.
> >               price = getCurrentSellPrice(company);
> >
> > Von: Stefan Frey<ste...@we...>
> > An: Erik Vos<eri...@xs...>
> > Cc: an 18xx game<rai...@li...>
> > Betreff: [Rails-devel] Fwd: 1830 RSM
> > Datum: Tue, 31 Jan 2012 16:15:26 +0100
> > Erik:
> > I forward you a report of a potentially critical bug: It does not
> > allow selling the director of the NYNH given that the operating
> > director owns the president share only and 2 other players have 20%
> > each and Pool having 30% only.
> >
> > This bug can be reproduced back to 1.5.3, unfortunately the save file
> > is not fully loadable under 1.5.2.
> >
> > I suspect this is related to the changes for 1835 at that time, I have
> > to admit that I cannot fully understand the code used to create the
> > actions for selling, so you might be in a better position to find this bug.
> >
> > Thanks,
> > Stefan
> >
> >
> > -------- Original Message --------
> > Subject: Fwd: 1830 RSM
> > Date: Tue, 31 Jan 2012 09:30:48 -0500
> > From: Bob Probst
> > To: stefan.frey
> >
> > Stefan, a friend of mine found this issue. I haven't confirmed it yet
> > but he's pretty thorough.
> >
> > I'm sure you can contact him directly if you have any questions
> >
> >
> > ---------- Forwarded message ----------
> > From: "Ing. Antonio Baracca"
> > Date: Tue, 31 Jan 2012 14:53:37 +0100
> > Subject: Fwd: 1830 RSM
> > To: Bob Probst
> > Cc: Palmiro Matteini
> >
> > Hi Bob,
> > we have found a major bug on the 1830 module.
> > The current player cannot sell 10% of NYNH from his president
> > certificate (remaining so with only 10% of NYNH and shifting the
> > presidency of the corporation).
> > I attach a saved file of the current 1830 game with the bug point.
> > I have seen you are currently in contact with programmers.
> > Can you please report to them this bug?
> > Thank you in advance.
> > Regards
> > Antonio
> >
> >
> >
> > Inizio messaggio inoltrato:
> >
> >> Da: "Palmiro Matteini"
> >> Data: 31 gennaio 2012 14.23.26 GMT+01.00
> >> A: "Ing. Antonio Baracca"
> >> Oggetto: Re: 1830 RSM
> >>
> >> Eccolo.
> >> Ciao.
> >>
> >> Palmiro Matteini
> >> pma...@om...
> >> ----- Original Message -----
> >> From: Ing. Antonio Baracca
> >> To: Palmiro Matteini
> >> Sent: Tuesday, January 31, 2012 11:46 AM
> >> Subject: Re: 1830 RSM
> >>
> >> Mandami la salvata che ci guardo
> >>
> >>
> >> Antonio Baracca
> >> ant...@ti...
> >>
> >> Il giorno 31/gen/2012, alle ore 09:28, "Palmiro Matteini" ha scritto:
> >>
> >>> Ciao Antonio.
> >>> Nella partita che stiamo facendo con Rail in ASGS, è successa una cosa
> strana.
> >>> Glauco ha venduto azioni della NYNH tenendosi solo il certificato della
> presidenza del 20%.
> >>> Al giro successivo c'erano altri giocatori che avevano il 20% e nel bank
> pool c'era il 30%.
> >>> Il programma stranamente non gli ha permesso di vendere il certificato
> della presidenza.
> >>> C'è un buco nel programma ?
> >>> Ciao.
> >>>
> >>> Palmiro Matteini
> >>> pma...@om...
> >
> > Antonio Baracca
> > ant...@gm...
> >
> >
> >
> > ----------------------------------------------------------------------
> > -------- Keep Your Developer Skills Current with LearnDevNow!
> > The most comprehensive online learning library for Microsoft
> > developers is just $99.99! Visual Studio, SharePoint, SQL - plus
> > HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when
> you subscribe now!
> > http://p.sf.net/sfu/learndevnow-d2d
> > _______________________________________________
> > Rails-devel mailing list
> > Rai...@li...
> > https://lists.sourceforge.net/lists/listinfo/rails-devel
> 
> 
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers is
> just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro
> Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Rails-devel mailing list
> Rai...@li...
> https://lists.sourceforge.net/lists/listinfo/rails-devel