Don't interpret silence as disagreement - I'm dead tired and in sufficient
agreement in case you want to get some sleep...
-Ben
On Feb 4, 2013, at 9:35 PM, "Derek Gaston"
<fried...@gmail.com<mailto:fried...@gmail.com>> wrote:
On Mon, Feb 4, 2013 at 10:15 PM, Derek Gaston
<fried...@gmail.com<mailto:fried...@gmail.com>> wrote:
And the alternative rebased log looks like "A, then D, then D+(B-A),
then D+(C-A)", right? And that's nice because it's more like what
we'd get from passing patches around, but in fact that intermediate
"D+(B-A)" state is one that never really existed and was never
actually tested.
A little more of a direct reply (just to be even more clear). What the rebased
log looks like (in your scenario): A, D, B, C (with the way you named them).
Just before the rebase you had this scenario:
upstream/master: A, D
roys_feature: A, B, C
When you do a rebase (git pull --rebase upstream master) you end up with:
upstream/master: A, D
roys_feature: A, D, B1, C1
ie you took your _new_ patches and "stacked" them on top of what was currently
sitting in master. If there were any collisions with D you fixed them up
during the rebase... so that's why B and C (possibly) changed to B1 and C1.
They might be slightly different from the B and C you started with. This is
normal and familiar to us though. The same thing happens when you do "svn up"
and fix collisions. Your local work has been modified somewhat because of what
someone did in trunk.
Now you quickly rerun your testing for B1 and C1 (just like with SVN) and
verify that everything is still good and then you push:
git push upstream HEAD:master
Meaning:
upstream/master: A, D, B1, C1
roys_feature: A, D, B1, C1
No merge commits get created. All collisions are dealt with _per patch_ which
means that there are no extraneous bits of commits mashed together in merge
commits... each patch is whole and complete and applies cleanly.
This means that if I pull and start working with master I get:
dereks_feature: A, D, B1, C1
And if I want to undo C1 for some reason I can simply do:
git reset HEAD~1 --hard
To get:
dereks_feature: A, D, B1
I don't have to worry about what happens when I undo a merge commit (does the
code even compile in that case? Are things just somewhat broken?). I can move
_linearly_ back through the history in master with impunity. No messy merge
commits to step around or try to understand.
Derek
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net<mailto:Libmesh-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
