What's the best way to use git to modify the history of master without affecting tags?

Question

I'm writing an example application for a book.

Every important commit is tagged (e.g. Ch01_Ex04, Ch03_Ex01) so that readers can get straight to the state of the application that they're interested in.

Every now and then I change my mind about something I did in the exxample and I'd like to go back in time and change, for example, a class name. I want that change to be applied from a given commit, without me needing to reset all the tags.

Say I have:

 Tag1    Tag2    Tag3
  |       |       |
- A - B - C - D - E
                  |
                 HEAD

Now I want to make a change between B and C, so I branch from B and make the change, and I have:

 Tag1    Tag2    Tag3
  |       |       |
- A - B - C - D - E
       \          |
        F        HEAD

What I want to get to is:

 Tag1        Tag2    Tag3
  |           |       |
- A - B - F - C - D - E
                      |
                     HEAD

I can't get my head around how to do this. Is there a way?

possible duplicate of [Can tags be automatically moved after a git filter-branch and rebase?](http://stackoverflow.com/questions/3150685/can-tags-be-automatically-moved-after-a-git-filter-branch-and-rebase) — Joe, Apr 26 '14 at 06:36

score 3 · Accepted Answer · edited May 23 '17 at 10:32

I'd like to go back in time and change, for example, a class name. I want that change to be applied from a given commit, without me needing to reset all the tags.

 Tag1    Tag2    Tag3
  |       |       |
- A - B - C - D - E
                  |
                 HEAD

What I want to get to is:

 Tag1        Tag2    Tag3
  |           |       |
- A - B - F - C - D - E
                      |
                     HEAD

Git's strongest guarantee is that nobody can do that.

It's simply not possible ("because math", specifically the math behind cryptographic hash functions) to insert commits into or make any other alteration to a history without everybody getting the modified history instantly detecting it.

The closest you can get is

 Tag1        Tag2    Tag3
  |           |       |
- A - B - F - C*- D*- E*
                      |
                     HEAD

where C*, D*, and E* are new commits that look almost exactly like C, D, E -- same commit message, author, date, what not, except for their hash codes. That means the tags have to get reset. git does not go out of its way to make rewrites at this scale easy.

The answer @Joe linked will show you how to move any orphaned tags after filter-branch is done rewriting history, assuming you go that route.

But I'd suggest you consider a different solution to your problem.

As I understand it, you want people to be able to find the current version of e.g. "Ch01_Ex04" easily, but those can change as the writing proceeds. Perfectly reasonable stuff. Thing is, tags aren't the right solution for that. They exist to identify a specific, fixed, historical content distribution.

What you want, identifying the current commit of content playing a particular role, might be best achieved by putting the status directly in the commit message itself and rather than referring to a commit by its tag name, instead identify it by that content: e.g. git show':/^===Ch01_Ex04===' will show the most recent commit on the current branch whose message starts ===Ch01_Ex04===.

Is that syntax for specifying a revision based upon text in the commit message correct? It's not behaving as expected here: "fatal: ambiguous argument ':/^Ch1_Ex01/': unknown revision or path not in the working tree." — Seb Rose, Apr 26 '14 at 08:43
What's in the slashes is a regular expression, so the leading `^` means "must match exactly at the start". The message you're getting says you don't have a commit with a message starting exactly "Ch1_Ex01" in your branch history. Play around with searching for text and patterns you know are there. — jthill, Apr 26 '14 at 08:49
*aggghh* it needs to not have a trailing slash. I typed a trailing slash reflexively and didn't notice. Take that out, it should work now. — jthill, Apr 26 '14 at 08:55
Thanks - I'd just found that in the documentation you linked, too! — Seb Rose, Apr 26 '14 at 08:57

AJ. · Answer 2 · 2014-04-26T06:00:08.787

To modify a commit that is farther back in your history, you must move to more complex tools. Git doesn’t have a modify-history tool, but you can use the rebase tool to rebase a series of commits onto the HEAD they were originally based on instead of moving them to another one. With the interactive rebase tool, you can then stop after each commit you want to modify and change the message, add files, or do whatever you wish. You can run rebase interactively by adding the -i option to git rebase. You must indicate how far back you want to rewrite commits by telling the command which commit to rebase onto.

For example, if you want to change the last three commit messages, or any of the commit messages in that group, you supply as an argument to git rebase -i the parent of the last commit you want to edit, which is HEAD~2^ or HEAD~3. It may be easier to remember the ~3 because you’re trying to edit the last three commits; but keep in mind that you’re actually designating four commits ago, the parent of the last commit you want to edit:

$ git rebase -i HEAD~3

Source git documentation for rewriting history

Doesn't look like what I'm asking for. I don't want to revert. I want to insert a new commit at a specific point in master's history, leaving all subsequent commits (and tags) in place. If git revert can do this, then please explain how, because I don't see it in the linked answer. — Seb Rose, Apr 25 '14 at 22:06
Based on your comment I modified my answer to suggest using interactive rebase. Take a look at the link for more details. — AJ., Apr 26 '14 at 06:01
Thanks @AJ, but rebase creates new commits, which don't have the tag, which means I need to move the tags, which is what I'm trying to avoid — Seb Rose, Apr 26 '14 at 08:31

What's the best way to use git to modify the history of master without affecting tags?

2 Answers2