<meta http-equiv="content-type" content="text/html; charset=utf-8"><span class="Apple-style-span" style="border-collapse: collapse; font-family: arial, sans-serif; font-size: 13px; "><div class="im" style="color: rgb(80, 0, 80); ">
>> We have our development branch ("master") and we prepare for a release<br>>> (simply stating our code is mature), so we branch "stable". A bug is found<br>>> in "stable", so we branch for bugfix or apply directly a bugfix (quick or<br>
>> not). At the same time we are working in new stuff on "master" _but_not_<br>>> bugfixing "master". Now we rebase "stable" changes onto "master", so the<br>>> quick fix is applied to "master" and a thorough fix can be applied later,<br>
>> without reverting the quick fix, simply a modifying commit.<br><br></div>>As far as I could understand, the suggested model was to merge<br>>"stable" into "master", not rebase it. Rebasing is what we do _now_,<br>
>in the form of cherry-picking.</span><br><br><div>I'm sorry but I didn't understand completely. In my opinion cherry-picking isn't the same as rebasing. Merging after cherry-picking is like committing twice the same changes and in separate positions, so merge conflicts and problems are likely. When you rebase you apply all the changes done in the other branch to your branch as if there wasn't ever a branch. This doesn't destroy the branch at all. Diagram:</div>
<div><br></div><div> /-D-F 2</div><div>-A-B-C-E-G 1 Initial situation</div><div><br></div><div><br></div><div> /-D-F-----\ </div><div>-A-B-C-E-G-H 1 After merge. Commits D and F are merged in H. Where there were 2 commits is now 1. Now we have to treat them as </div>
<div> a whole instead of separately, which could potentially be a PITA if there is any problem that could be </div><div> addressed in one of the commits only. Branch 2 is closed (or the same as 1).</div>
<div><br></div><div> 1</div><div> | </div><div>-A-B-C-E-G-D-F After rebase 1. The changes in branch 2 are applied over the changes in branch 1. No additional commit, just </div><div> | reordering of commits. No merge conflict possible. If you want you can merge 1 on 2 without adding </div>
<div> 2 another commit (straight-forward merge). It looks as if all the work was done in the same branch </div><div> instead of separate branches. WARNING: If there is parallel work in both branches you could have </div>
<div> reverted to a previous state or created some problems.</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><meta http-equiv="content-type" content="text/html; charset=utf-8"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>
</div><div><br></div><div> /-D-F 2 </div><div>-A-B-C-E-G-F 1 After cherry-picking F. Commit F is applied to both branches (it actually wouldn't be exactly the same commit to git) </div>
<div> Further merges will try to apply changeset F upon changeset F providing potentially difficult </div><div> merging conflicts.</div>
<div><br></div><div>I don't know if it's clearer now or simply I didn't understand completely your statement. Also, I'm not saying which is better or that there is a better. I think there are no guarantees of problems with any approach, just the potential. I personally prefer rebasing over merging, but I have neither worked with a source as complex as scummvm nor with a team as big myself. I learned git using <a href="http://progit.org/book">http://progit.org/book</a> and consult it from time to time as I use git occasionally.</div>
<div><br></div><div>Either way the best approach is the one you are most comfortable with because you are the ones using it and responsible for it.</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>
<div><br></div><div>Miguel</div><div><br></div><div><div class="gmail_quote">2011/5/31 Marcus Comstedt <span dir="ltr"><<a href="mailto:marcus@mc.pp.se">marcus@mc.pp.se</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Tarek Soliman <<a href="mailto:tarek-spam@zeusmail.bounceme.net">tarek-spam@zeusmail.bounceme.net</a>> writes:<br>
<br>
[...]<br>
<div class="im">> When I say "this stinks of svn" I don't mean svn is inherently evil or immoral. I am saying the svn way is a workaround that was the best one could do given the crappy tool.<br>
<br>
</div>Neither svn or git is evil or immoral, but we have a pretty good<br>
picture of what the best is we could do with that crappy tool (svn).<br>
Now we need to figure out what the best we can do with _this_ crappy<br>
tool (git) is, and how to get around the bits that "stink of git". :-)<br>
<font color="#888888"><br>
<br>
// Marcus<br>
</font><div><div></div><div class="h5"><br>
<br>
<br>
------------------------------------------------------------------------------<br>
Simplify data backup and recovery for your virtual environment with vRanger.<br>
Installation's a snap, and flexible recovery options mean your data is safe,<br>
secure and there when you need it. Data protection magic?<br>
Nope - It's vRanger. Get your free trial download today.<br>
<a href="http://p.sf.net/sfu/quest-sfdev2dev" target="_blank">http://p.sf.net/sfu/quest-sfdev2dev</a><br>
_______________________________________________<br>
Scummvm-devel mailing list<br>
<a href="mailto:Scummvm-devel@lists.sourceforge.net">Scummvm-devel@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/scummvm-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/scummvm-devel</a><br>
</div></div></blockquote></div><br></div></div>