Welcome to Software Development on Codidact!
Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.
1 answer
Each of them has an analog to another Git command. But instead of objects in the repository, these take text file(s) created either by you or someone else.
git apply
Think of this as Applying a git stash from a text file.
Applies a delta to your worktree. It's nominally a Git-flavored version of GNU patch that uses Git's diff machinery. This command can take diffs from several formats, making it more versatile than git am but less powerful.
git am
Think of this as Cherry-picking a commit range from text file(s).
Applies commits to your HEAD. This could be a single commit or a series of them; keeping the same author, title, body, author date, etc.[1] It does require that the diff was generated by git format-patch or git send-email, so it's less versatile than git apply but more powerful.
Several notable projects[2] don't use public repos and pull requests for upstreaming code. Instead they share patch text for the maintainer to apply and evaluate. Usually these patches are traded by email with the git send-email command. I suspect that the original mnemonic for git am was "Git apply [from] mailbox."
When to use
git am
- When you want attribution and metadata.
- When you want a series of commits.
git apply
- When you want to tinker with the delta before committing.
- When the diff is not from
git format-patchorgit send-email.
-
git amkeeps the original author and author date, but the committer and committer date are set to you and now, respectively. This means that your commit hash will be different from the patch creator's. If your commits of their code become canonical, they will want to rebase or make new branches from your canonical version. ↩︎ -
Notable projects maintained by email include the Linux kernel and Git itself. You can browse the Git mailing list history to see patches and commentary. Any thread with
[PATCH ... ]in the subject line is a prospective commit series and discussion on it. ↩︎
0 comment threads
0 comment threads