lol - I wasn't. It's not that late here and I wanted to get across these
ideas. Take your time and read them when you get a chance (or don't! ;-)
and hit me back with replies when you get around to it.
Sorry to go nuts on the list... I just want to get us all on the same page.
Even if we don't use this method of using Git... at least we can have some
good intelligent discourse about it first ;-)
Derek
On Mon, Feb 4, 2013 at 11:01 PM, Kirk, Benjamin (JSC-EG311) <
benjamin.kir...@nasa.gov> wrote:
> 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> wrote:
>
> On Mon, Feb 4, 2013 at 10:15 PM, Derek Gaston <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
> 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
