1

I have a repository with some commits. I want these commits replayed on a different copy of the repository in the exact same order, same commit messages, etc.

I'm hoping there is some combination of git-log, patch, and git-commit that can re-run the commits on the new repository.

Dale Forester
  • 18,145
  • 10
  • 27
  • 27

1 Answers1

2

You can add the other repository as a remote and fetch all changes. That way you will have the exact same commits in the same order, same hashes. I don't understand why you would want to go the route of format-patch + am. git bundle might also be an option for you.

Community
  • 1
  • 1
knittl
  • 246,190
  • 53
  • 318
  • 364
  • I was hoping for something really quick. I've read other similar questions that talk about adding remotes, rebasing, cherry-picking, etc. Seems like a lot of hassle just to want to apply commit diffs w/commit messages to another repository which may be the same repository but may not have the same history. – Dale Forester Sep 29 '11 at 16:50
  • 1
    @DaleForester: How can a repository "be the same repository, but may not have the same history"? That's simply not possible. And you don't need to rebase, simply fetch the commits and merge them (most probably resolving in a fast-forward) – knittl Sep 29 '11 at 17:16
  • @knittl What he meant with "same repo but different history" is that both were probably started from the same sources (e.g. tar-file) but with tiny-tiny differences (like the *author* who did the initial `git init; git add .`). Thus the *commit-ids* differ. I think he would like to have git resolve for him what changes have been applied already between the two repos -- but because they have different commit-ids for virtually the same commit-content git may have a hard time to do all its auto-merge-magic. – towi Jul 10 '13 at 13:35
  • Git grafts might be your friend then. Although rebase/format-patch/cherry-pick all take manually specified ranges. – knittl Jul 10 '13 at 17:01