CODEWITHSUNDEEP
gitversion-controlformat-patchgit-am
Sophia_ES
Sophia_ES

Reputation: 1361

Preserving commit ID-tag with "git am"

I attempted (on a small test repository) to export the repository into a series of .patch files generated with a git format-patch command for each commit and then to reconstitute the repository by using "git init" on an empty directory followed by a git apply command for each patch file. It worked --- only one problem ---- when git am applies a patch to a repository instead of preserving the patch's ID-tag, it generates a new one. This can be a problem later on, as it can make it difficult to determine which commits are redundant and which ones are not.

As for why I don't use normal methods of cloning a repository like git clone -- the answer is that generally speaking, I do use git clone to clone a repository - but I have very specific reasons at the moment to try to see if I can do it this way that are too long to go into detail here (though I may allude to the reason later on in this question) --- and not only are those reasons too long, but I fail to see how their final details can affect what the correct answer to this question is.

However, if you tell me that .patch isn't the correct file-format to use for this purpose, that I'm open to. What is most essential that I want to do is:

  1. Extract individual commits to the repo to individual files -- and to know the order of those files in the repo history etc.

  2. Be able to completely reconstitute the repo based on those extracted versions of the commits

  3. Later on be able to "de-canonize" any commit that I identify that shouldn't have been made (and which keeping in the repository's history would not be worth the bloat it would cause to the project history-size) so that I can re-constitute the repo without the "de-canonized" commits. (And by the way, aspect #3 ties in very much to the reason why I want to be able to do this.)

Upvotes: 3

Views: 1990

Answers (2)

Guildenstern
Guildenstern

Reputation: 3841

You can’t use git-format-patch(1) as a transport format like git-clone(1) since it doesn’t deal with merge commits. There’s also the missing committer metadata problem.

Upvotes: 0

Andrew C
Andrew C

Reputation: 14883

I am not 100% clear what you are asking here. I'm going to presume that when you say "commit ID-tag" you mean SHA. And I don't know at all what you mean by "patch ID-tag".

So guessing ...

When you create a commit in git it has 6 pieces of meta-data attached to it. Those are Author Name/Email/Time and Committer Name/Email/Time. If you are creating a new commit from scratch the author name/email and committer name/email will both match.

They don't have to do. You can override them via GIT_AUTHOR_NAME and similar environmental variables. Of if you cherry-pick or rebase it will modify them.

When you run git format-patch it doesn't provide you with the committer information at all. Likewise when you run git am it doesn't look for the committer information, instead overwriting it with the name and email of whomever is running git am. This will result in a different SHA being created if that information changes.

No easy way to get around it (you would have to hack both format-patch and am to preserve comitter info. However, instead of comparing the commit SHAs you could calculate the commit Patch ID (git patch-id) and compare those. They should be identical.

Upvotes: 5

Related Questions