Roy posited this on GitHub and I wanted to respond:
> At worst they screw with bisections... and with backtracking and
> > undoing changes in general.
> I'd have expected the opposite to be true. That may just mean I don't
> understand git yet.
> Master begins in state A; I change it to state B, then C, testing as I
> go. In the meantime someone has pushed state D to master.
> In this case, the merged sequenced log looks like "A, then D, then B,
> then C, then D+(C-A)", right? So that's confusing because the D->B
> transition looks like a reversion, but it ought to be pretty nice for
> regression testing, because B and C were exactly the same as the
> states I tested.
> 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.
Before diving in. Let's think about what this situation would look like
with SVN:
1. Master starts at commit #1 A
2. People commit #2 and #3, B and C
3. You've been working on your own and you're ready to commit your
changes. You do "svn up" and fixup any collisions. You test your current
changes one more time and "svn commit"... creating D.
That means that "master" (trunk) now looks like:
A, B, C, D
Nice and tidy and linear. This is exactly what we can achieve with Git
with a single master and using rebase for feature branches. Here's how it
works:
1. Master starts at commit A
2. You branch from A and start working.
3. B and C get pushed to master while you're working.
4. You've created patches D and E (starting from A) in your local repo and
you are ready to push your new feature.
5. You fetch upstream:
git fetch upstream
6. You rebase your patches on top of what's been put into master:
git rebase upstream/master
7. Fix any collisions during the rebase (similar to dealing with "svn up")
8. Now your local branch looks like A, B, C, D, E... and you're ready to
push:
git push upstream HEAD:master
9. Everyone enjoys an uncluttered master that looks like A, B, C, D, E...
nice, tidy, and linear.
BTW: You can do steps 5 and 6 simultaneously by doing:
git pull --rebase upstream master
This is what I usually do. I separated them into two steps just to be more
clear.
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
