Re: How to rewrite author history

I imported my git repo from an SVN repo, and the authors have email@SOME-GUID for their email address rather than their actual one (probably courtesy of Google Code hosting). Rewriting history and changing all the commit hashes isn't a problem at this point in development, so how can I do a massive search-and-replace to replace several specific author emails with the valid ones?

On Fri, Mar 21, 2008 at 7:41 PM, Andrew Arnott <andrewarnott@gmail.com> wrote:

Please, take a look at man git-filter-branch. I believe you can do that using env-filter, but I have never used this filter myself.

Dmitry

Andrew> I imported my git repo from an SVN repo, and the authors have Andrew> email@SOME-GUID for their email address rather than their Andrew> actual one (probably courtesy of Google Code hosting). Andrew> Rewriting history and changing all the commit hashes isn't a Andrew> problem at this point in development, so how can I do a Andrew> massive search-and-replace to replace several specific author Andrew> emails with the valid ones?

If you can reimport it, you can use the "--authors-file" of "git svn".

  Sam

Thanks. Re-importing from SVN isn't an option any more, but I ended up with something like this that seems to have worked.

git checkout master git-filter-branch --env-filter ' if [ "$GIT_AUTHOR_NAME" = "andrewarnott" ]; then export GIT_AUTHOR_EMAIL="andrewarnott@gmail.com" export GIT_AUTHOR_NAME="Andrew Arnott" fi export GIT_COMMITTER_EMAIL=$GIT_AUTHOR_EMAIL export GIT_COMMITTER_NAME=$GIT_AUTHOR_NAME '

And I did this for master, and my v1 and v0.1 branches. I'm concerned though, that since I changed the names of all the objects by doing this, did I somehow make my branches incompatible with each other? Will there be any problems in the future sharing commits or merging across branches as a result?

Thanks.

On Sat, Mar 22, 2008 at 2:29 AM, Samuel Tardieu <sam@rfc1149.net> wrote:

On Sat, Mar 22, 2008 at 06:11:12AM -0700, Andrew Arnott wrote:

There are two concerns, and I'm not sure which you have (I think number 1):

  1. Your branches within the repository will not connect anymore. I
     believe this is a non-issue with your filter, since the generated
     commit IDs are deterministic. Certainly a toy case worked for me
     with:

       for i in master branch; do
         git filter-branch --env-filter=... $i
       done

     You can also specify both to be done at the same time, which is
     more efficient:

       git filter-branch --env-filter=... master branch

     You can check the graph structure with "gitk master branch" which
     should show them connecting.

  2. Your branches are now a different, rewritten history compared to
     anyone who has cloned or fetched from you. This is unavoidable, and
     the answer is either "don't use filter-branch" or "tell everyone to
     rebase their work on the new history." So the best time to
     filter-branch is right after import, but before you start work.

-Peff

Thanks, Jeff. That was very helpful. I have published my repo online already, but only a couple people (if even that) have cloned it by now and I am prepared to email the list of interested parties letting them know. About this rebasing thing, is there a better way than for them to just wipe their repo and clone again? Would a simple git fetch and git rebase do the trick?

Thanks again, everyone.

On Sat, Mar 22, 2008 at 9:57 AM, Jeff King <peff@peff.net> wrote:

On Sat, Mar 22, 2008 at 12:06:37PM -0700, Andrew Arnott wrote:

Short answer: if they haven't done any work on top of yours, re-cloning is probably the simplest route.

If they do have work, then they will want to fetch and rebase. The commands are fairly simple, but what is happening is a little tricky, so I'll subject you to some ascii art.

  # user has commits C..D built on top of your original A..B (in the
  # diagram, "..." refers to an arbitrary number of commits)
  #
  #  A--...--B <-- origin/master
  #           \
  #            C--...--D <-- master
  git fetch

  # after the fetch, we now have the filtered A'..B' pointed to by
  # origin/master, but the reflog for origin/master points to the
  # original.
  #
  # A'--...--B' <-- origin/master
  # A--...--B <-- origin/master@{1}
  #          \
  #           C--...--D <-- master
  #
  # so now we can rebase. We want all of the commits between the
  # _original_ upstream and our current state to be rebased on top
  # of the new upstream.
  git rebase --onto origin/master origin/master@{1} master

Three things to note here.

1. This works even if C..D is empty, so it is valid even if they didn't
do any work. Though in that case, simply doing "git reset --hard
origin/master" would work just as well.

2. The annoying thing is that you have to do this for every branch. So
depending on how many branches you have and how much work they did, it
may just be simpler to export the work as patches, re-clone, and then
apply:

  git checkout master
  git format-patch origin/master >/some/path/outside/repo
  cd .. && rm -rf repo
  git clone /path/to/repo && cd repo
  git am /some/path/outside/repo

3. Since you haven't changed the trees at all, a fetch will just need to
download the new commits. Thus a fetch should be way less
network-intensive than a re-clone. Whether that matters, of course,
depends on your repo size and your users' bandwidth.

Hope that helps, -Peff