0

Let me start by briefly describing our setup. We have a "master" GitHub repo to which we can only contribute via pull requests. We also have a private fork on GitHub where all the work happens, and from where we actually create pull requests. Finally, there's a local clone of that private fork.

The task at hand is to rewrite a multitude of commit messages, and obviously git filter-branch is the tool of choice here.

I've created a temporary branch in my local cloned repo and successfully did all the filtering there - which apparently created an "alternative history" with all the commits affected by the filter. Then, as described in https://stackoverflow.com/a/15256575, I've rebased the local master onto the temporary branch.

Now the question is - what would be the safest way to:

  1. Update the GitHub fork so that the other people on the team are unaffected (we can coordinate necessary activities so this update does not happen unexpectedly). I suppose git push --force-with-lease could be the way to go, however I've never tried it in conjunction with filter-branch so I am not at all sure if that's a good idea.
  2. Propagate the changes to the master repo via a pull request

Thanks!

Community
  • 1
  • 1
DmytroL
  • 586
  • 1
  • 3
  • 16
  • "*The task at hand is to rewrite a multitude of commit messages*" ... in `master`? – Schwern Mar 10 '17 at 17:53
  • @Schwern You caught me off guard :) Eventually, yes, these rewritten commits shall end up in the master branch of the "master" repo. But I am not sure if we need to perform the actual rewrite on the master branch of the private fork as we could create a pull request from any branch in the private fork – DmytroL Mar 10 '17 at 17:58
  • What caught my attention is that you did a filter and then "*rebased the local master onto the temporary branch*" which doesn't make sense. What was that temporary branch a temporary branch of? master? Could you show exactly what you did? The `history` command will prove useful. – Schwern Mar 10 '17 at 18:05
  • @Schwern, sure, it was something like this: git checkout master git branch temp git checkout temp git filter-branch .... git checkout master git rebase temp This was my (possibly incorrect) interpretation of this StackOverflow answer: http://stackoverflow.com/a/15256575 – DmytroL Mar 10 '17 at 18:19

1 Answers1

1

That answer about making a temp branch and rebasing back applies to something else. If you rebased your filtered branch (which is master) on top of master I'm not sure what state your repo is in now.

You'll want to undo that by resetting master back to where it was. If you didn't make any additional commits on master you can probably reset back to origin/master using git reset --hard origin/master. Then do the filter on master.

Normally you wouldn't use a pull request for this sort of surgery. PRs are for well behaved feature branches, not rewriting history (though you can safely rewrite branches which have been submitted as PRs). Instead you'd do the filter, check it's correct, git push --force, and let everyone know master has been rebased. I don't think pull requests are set up for this sort of thing.

Here's why. Let's say the first change the filter makes is at C. The result is basically a new branch.

 A - B - C - D - E - F - G - H [origin/master]
      \
       C1 - D1 - E1 - F1 - G1- H1 [master]

Because a commit is defined by the previous commit, when you rewrite one commit Git has to rewrite all of its children. Even if they contain the same content, they'll be different commits with different commit IDs.

If you were to submit this as a pull request... I'm not sure what Github is going to do. Either it's going to treat it as a branch and make a big mess, or Github has some magic about rebasing. Try it? Send it as a PR and see what Github does with it. If it doesn't work, delete the PR and do it manually.

The other, AFAIK, unavoidable problem is once your filtering is pushed upstream everyone is affected. Everyone will have to git pull --force and everyone will have to rebase their branches on top of the new master.

So consider whether the filtering is worth it just to change a few commit messages.

Schwern
  • 153,029
  • 25
  • 195
  • 336