Git: master back to timestamp and test running with each commits?

Question

There are 5 commits that contain a new experimental feature, yet it makes master too slow, reason still unknown. How can I stash the newer commits or create a branch for them like ExpA so they do not mess up with the master branch?

Separate dir idea

Gererate from

...--o--o--A--B--C--D--E   <-- master

the following repos to separate dirs A, B, C, D and E in that order:

...--o--o--A   <-- master

...--o--o--A--B   <-- master

...--o--o--A--B--C   <-- master

...--o--o--A--B--C--D   <-- master

...--o--o--A--B--C--D--E   <-- master

but it is also possible to reformulate the goal in terms of branches so instead of creating separate dirs, create new branches A, B, C, D and E so it is easy to run the tester.m file just by changing branch.

Separate branch idea

     ---- A   <-- A
     |
     |------ A--B   <-- B
     ||
     || --- A--B--C   <-- C
     || |
     || |  A--B--C--D   <-- D
     \\ | /
      \\|/
...--o--o   
         \
          A--B--C--D--E   <-- master

How would test each commit and why? With some of the above ideas?

Suggest also other ideas if you have them! There may be some GUI program where having cursor above commit and pressing some key runs the stage -- this kind of feature would btw be supercool in Tig.

Answer 1

Let's say your master branch looks like this:

    --A--B--C--D--E--F--G (master)

C, D, E, F, and G are the commits that you no longer want on master. So your goal is to make them be a branch, and have master reset to B. Therefor,

(0) git checkout master

(1) git branch experimental G

(2) git reset --hard B

That will leave you with:

    --A--B (master)
          \
           C--D--E--F--G (experimental)

Now you can build master without the experimental commits; and on the experimental branch, you can build everything.

Answer 2

Perhaps, source Freenode's Git channel.

git checkout -b <newbranchname> 'master@{2014-01-11 22:35}'

Answer 3

What you need to know here is that a "structural branch" (I'm experimenting with this term now) is formed by the commit graph, while a git branch label is merely "pasted onto" a commit (or "points to" a single commit, if you prefer that terminology).

It sounds like you have something like this right now:

...--o--o--A--B--C--D--E   <-- master

where A through E are the five commits that are this new experimental feature, and the earlier os are other commits. (Note that "time moves forward" left-to-right, i.e., the last o commit happened before A, and A happened before B, and so on.)

Let's draw the above with a kink in the line, which does not change it in any way, but makes room in the drawing for us to stick a second label on it. Then, let's stick a second label on it.

...--o--o   <-- new-label
         \
          A--B--C--D--E   <-- master

See how, if we could just swap those two labels, we'd have exactly what you asked for: master would point to the last commit just before A, and new-label would point to commit E which then "branches off master".

We can do exactly that. There's only one caveat: if anyone else is sharing this repository, either directly or (more commonly) via push and pull operations, the other people only expect branch labels to "move forward": to have new commits added over time, not to have commits "taken away" by going "back in time".

If they've picked up both your new commits (A through E) and the action of "moving the branch label master forward" from the last o commit up to E, and then you decide to "move the label backward", you must somehow tell them: "hey, guys, sorry, but I had to move the label backward in time". Then they may have to take more actions on their own to recover from this.

If nobody else has the commits yet, you're in great shape. If others might have them but are not using them, or are OK with taking actions to recover from "moving backward", then you're still in good shape.

Here's one shortest-way to achieve the trick with the labels (there are a few more equally short ways):

1. Add a new label pointing to commit E:

   git checkout master  # if you're not already "on branch master"
   git checkout -b ExpA
   

   (this method has the advantage of leaving you "on branch ExpA", which I assume you'd like to be).

2. Now that there's a second label on E, forcibly move master back five commits:

   git branch -f master master~5
   

   (master~5 means "move back 5 commits from where master is now; you can use any other method to name the desired commit, which is the last o node in the drawings above; master@{date} as in your own answer can do the trick, for instance).

3. Only if you've already pushed commits A through E to some central repository (here, I assume it's called origin) on branch master. Note that this step is at least slightly dangerous (sometimes more than slightly, if others have pushed more commits onto master over there) and should not be done until everyone else knows about this and has agreed to it (and if you don't know what you're doing here, let someone else—someone who's in charge of the central repository origin—do it instead):

   git push -f origin master
   

If others have your commits and you are not allowed to "go back in time" with the labels, you'll need to "revert" stuff instead; see other StackOverflow discussions about this.