Ask HN: How to Do This in Git | Hacker News Reader

Ask HN: How to Do This in Git

2 pointspm22225 comments

Suppose I'm writing a tutorial and as a simple example there's only one source file. Incremental changes will be made to this file step by step along the way. So far I this have commit history: commit1-commit2-commit3-...-commit100-(Head)

commit1:

  This is step1

commit2:

  This is step1
  This is step3

commit3:

  This is step1
  This is step3
  This is step3

Commit100:

I wish to be able to tell readers to go to commitX for source file of stepX.

Now obviously in commit2 there's a typo and it's inherited by commit3 and so on. What's the best way to achieve my goal, is it a natural thing for git to do?

View on HN

Branch at commit1, make a new commit2, commit2a, then rebase commit3 onto commit2a

interactive rebase can do this:

    git rebase -i commit1

it will open an editor. find commit2 in the text file and change "pick" to "edit". save&exit editor

it will dump you out on commit2 (with the typo). use an editor to fix the typo in typofile. then:

    git add typofile
    git commit --amend
    git rebase --continue

then it will rebase the other 99 commits on top, if there are any conflicts it will stop and you'll have to fix them.

you can optionally skip the git commit --amend right after git add and rebase --continue does it automatically anyway.

Since the typo is inherited in commit3+, conflict is guaranteed after commit2 is amended, right? Is there a way to automate this? I do appreciate the clean commit history with this approach.

No, if the lines around the change are stable, it should resolve itself. Assuming that after line commit3 was edited, the future changes occur further down in the file, (which is usual). At worst, it should be OK after a conflict or two.

NOTE: also this is just a different way of performing the same thing as the other rebase suggestion. It's also the same as cherry-picking each newer commit manually. All methods will have the same amount of conflict resolution.

UPDATE: I just constructed this exact scenario to test it and can confirm that if your sequence is exactly as described, you'll get one conflict commit #3 after you edit commit #2. After it's resolved, the other 98 commits are automatic.

Great it works just as you describe.

I notice that the commit hashes change except commit1. Would tag be stable with rebase operation and can be used in my case? Perhaps it's too much to ask git.

Reply on news.ycombinator.com