Except you've thrown away everything that's happened since 1973, some of which you may still want. There's going to be a lot of awful lot of manual conflict resolution to handle - or is there a "world" script that can be run off the new HEAD that plays out the series of events that result from the sentinels being prevented?
I suppose that's true. Maybe the desired commits could be cherry picked onto the branch before you make the branch into master.
The new X-Men movie explained in Git
21–30 of 41 posts
Re: The new X-Men movie explained in Git
#22Also: the movie starts with a branch where nearly everyone dies, and Kitty Pride/Bishop reverts a few commits.
Re: The new X-Men movie explained in Git
#23Earlier quoted context omitted.
I suppose that's true. Maybe the desired commits could be cherry picked onto the branch before you make the branch into master.
The problem is that the software architects didn't separate concerns very well in architecting the World system. So subtle bug fixes could have unexpected consequences if they were just cherry-picked in!
Re: The new X-Men movie explained in Git
#24This had the exact opposite effect on me of further explaining some Git features via the X-Men movie!
Re: The new X-Men movie explained in Git
#25Re: The new X-Men movie explained in Git
#26Except you've thrown away everything that's happened since 1973, some of which you may still want. There's going to be a lot of awful lot of manual conflict resolution to handle - or is there a "world" script that can be run off the new HEAD that plays out the series of events that result from the sentinels being prevented?
Re: The new X-Men movie explained in Git
#27Re: The new X-Men movie explained in Git
#28Re: The new X-Men movie explained in Git
#29http://mercurial.selenic.com/wiki/BisectExtension
As for git stash, the closest equivalent appear[1] to be the shelve extension (distributed with mercurial since 2.8, November 2013):
http://mercurial.selenic.com/wiki/ShelveExtension
However, as we'll be needing to do a bit of history editing, we might want to just go straight for the (also bundled with mercurial) queues extension:
http://mercurial.selenic.com/wiki/MqExtension
Also relevant:
http://mercurial.selenic.com/wiki/EditingHistory http://mercurial.selenic.com/wiki/MqTutorial
I'm a little tempted to redo this for mercurial, just to look at the differences -- but the first order would be to create an actual repo -- say just a file with timestamps and events:
-479: Artaÿctes crucified
(...)
1973: Wolverine wakes up in random bed
1973: Mystique kills Trask
1973: Mystique's DNA stolen
xx: Last mutant killed by sentinel
(With every commit appending one or more lines).That way we could use it as a nice way to compare work flows across scms... Who's up for doing RCS?
Come to think of it, as the initial series of commits are linear, they could be specified in some linear fashion (yml maybe) -- and then replayed to create the initial "broken" state -- then one would only have to document the "fixing" part for different systems... Another alternative would be to convert (eg via mercurials git/svn plugins -- but I don't think they cover bzr, monotone and rcs...).
[1] http://selenic.com/pipermail/mercurial/2011-December/041164....