Live data from Hacker News

The new X-Men movie explained in Git

hashrocket.com

21–30 of 41 posts

Re: The new X-Men movie explained in Git

#21
post #20

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 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

#23
post #21
post #20

Earlier 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!

The world is made of unexpected consequences.

Re: The new X-Men movie explained in Git

#26

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 think the idea is that you don't have access to the other timeline, because none of the characters should. All that's left of the dark timeline is in Wolverines's head, which is accounted for!

Re: The new X-Men movie explained in Git

#29
Nice intro to (advanced) git :-) If anyone else was curious about the state of bisect in mercurial (it's been in standard mercurial for a while):

http://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....

Post reply on HN