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.
Post History
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 g...
Answer
#7: Post edited
by
Michael
·
2024-02-02T17:28:00Z (3 months ago)
Link the Git mailing list
- 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`][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.[^author-committer] 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[^patch-projects] 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-patch` or `git send-email`.
- [^author-committer]: `git am` keeps 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.
[^patch-projects]: Projects including Git itself.- [patch]: https://man7.org/linux/man-pages/man1/patch.1.html
- 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`][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.[^author-committer] 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[^patch-projects] 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-patch` or `git send-email`.
- [^author-committer]: `git am` keeps 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.
- [^patch-projects]: Notable projects maintained by email include the Linux kernel and Git itself. You can browse [the Git mailing list history][git-lore] to see patches and commentary. Any thread with `[PATCH ... ]` in the subject line is a prospective commit series and discussion on it.
- [patch]: https://man7.org/linux/man-pages/man1/patch.1.html
- [git-lore]: https://lore.kernel.org/git/
#6: Post edited
by
Michael
·
2024-01-26T20:11:12Z (4 months ago)
Move the analogs to the top of each section. Explicitly mention email.
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 by someone else.- # `git apply`
Applies a **delta** to your **worktree.** It's nominally a Git-flavored version of [`patch`][patch]. It's more versatile than `git am` but less powerful._Think of this as **"Applying a `git stash`"** from a text file._- # `git am`
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. It does require that the diff was generated by `git format-patch`, so it's less versatile than `git apply` but more powerful._Think of this as **"Cherry-picking a commit range"** from text file(s)._Several notable projects don't use public repos and pull requests for upstreaming code. Instead they share patches directly as these text files for the maintainer to apply and evaluate.- # 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-patch`.- [patch]: https://man7.org/linux/man-pages/man1/patch.1.html
- 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`][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.[^author-committer] 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[^patch-projects] 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-patch` or `git send-email`.
- [^author-committer]: `git am` keeps 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.
- [^patch-projects]: Projects including Git itself.
- [patch]: https://man7.org/linux/man-pages/man1/patch.1.html
#5: Post edited
by
Michael
·
2024-01-17T15:37:45Z (4 months ago)
Ugh. Proofreading
- 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 by someone else.
- # `git apply`
- Applies a **delta** to your **worktree.** It's nominally a Git-flavored version of [`patch`][patch]. It's more versatile than `git am` but less powerful.
- _Think of this as **"Applying a `git stash`"** from a text file._
- # `git am`
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. It does require that the diff was generated by `git format-patch`, so it's less versatile than `git apply`, but it's more powerful.- _Think of this as **"Cherry-picking a commit range"** from text file(s)._
- Several notable projects don't use public repos and pull requests for upstreaming code. Instead they share patches directly as these text files for the maintainer to apply and evaluate.
- # 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-patch`.
- [patch]: https://man7.org/linux/man-pages/man1/patch.1.html
- 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 by someone else.
- # `git apply`
- Applies a **delta** to your **worktree.** It's nominally a Git-flavored version of [`patch`][patch]. It's more versatile than `git am` but less powerful.
- _Think of this as **"Applying a `git stash`"** from a text file._
- # `git am`
- 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. It does require that the diff was generated by `git format-patch`, so it's less versatile than `git apply` but more powerful.
- _Think of this as **"Cherry-picking a commit range"** from text file(s)._
- Several notable projects don't use public repos and pull requests for upstreaming code. Instead they share patches directly as these text files for the maintainer to apply and evaluate.
- # 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-patch`.
- [patch]: https://man7.org/linux/man-pages/man1/patch.1.html
#4: Post edited
by
Michael
·
2024-01-17T15:36:46Z (4 months ago)
Some intro text.
- # `git apply`
This applies a **delta** to your **worktree.** It's nominally a Git-flavored version of `patch`. It's more versatile than `git-am` but less powerful.- _Think of this as **"Applying a `git stash`"** from a text file._
- # `git am`
This applies **commits** to your **`HEAD`.** It could be a single commit or a series of them, keeping the author, message, authordate, etc. It does require that the diff was generated by `git format-patch`, so it's less versatile than `git-apply`, but it's more powerful.- _Think of this as **"Cherry-picking a commit range"** from text file(s)._
Several notable projects don't use public repos and pull requests for upstreaming code. Instead they share patches directly as these `format-patch` text files for the maintainer to apply and evaluate.- # 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-patch`.
- 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 by someone else.
- # `git apply`
- Applies a **delta** to your **worktree.** It's nominally a Git-flavored version of [`patch`][patch]. It's more versatile than `git am` but less powerful.
- _Think of this as **"Applying a `git stash`"** from a text file._
- # `git am`
- 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. It does require that the diff was generated by `git format-patch`, so it's less versatile than `git apply`, but it's more powerful.
- _Think of this as **"Cherry-picking a commit range"** from text file(s)._
- Several notable projects don't use public repos and pull requests for upstreaming code. Instead they share patches directly as these text files for the maintainer to apply and evaluate.
- # 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-patch`.
- [patch]: https://man7.org/linux/man-pages/man1/patch.1.html
#3: Post edited
by
Michael
·
2024-01-17T15:30:16Z (4 months ago)
- # `git apply`
- This applies a **delta** to your **worktree.** It's nominally a Git-flavored version of `patch`. It's more versatile than `git-am` but less powerful.
_Think of this as **"Applying a `git stash`"** from a text file created by you or someone else._- # `git am`
- This applies **commits** to your **`HEAD`.** It could be a single commit or a series of them, keeping the author, message, authordate, etc. It does require that the diff was generated by `git format-patch`, so it's less versatile than `git-apply`, but it's more powerful.
_Think of this as **"Cherry-picking a commit range"** from text file(s) created by you or someone else._- Several notable projects don't use public repos and pull requests for upstreaming code. Instead they share patches directly as these `format-patch` text files for the maintainer to apply and evaluate.
- # 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-patch`.
- # `git apply`
- This applies a **delta** to your **worktree.** It's nominally a Git-flavored version of `patch`. It's more versatile than `git-am` but less powerful.
- _Think of this as **"Applying a `git stash`"** from a text file._
- # `git am`
- This applies **commits** to your **`HEAD`.** It could be a single commit or a series of them, keeping the author, message, authordate, etc. It does require that the diff was generated by `git format-patch`, so it's less versatile than `git-apply`, but it's more powerful.
- _Think of this as **"Cherry-picking a commit range"** from text file(s)._
- Several notable projects don't use public repos and pull requests for upstreaming code. Instead they share patches directly as these `format-patch` text files for the maintainer to apply and evaluate.
- # 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-patch`.
#2: Post edited
by
Michael
·
2024-01-17T15:29:22Z (4 months ago)
Mention patch creation reqs.
- # `git apply`
This applies a **delta** to your **worktree.** It's nominally a Git-flavored version of `patch`.Think of this as _"Applying a `git stash`"_ from a text file created by you or someone else.- # `git am`
This applies **commits** to your **`HEAD`.** It could be a single commit or a series of them, keeping the author, message, authordate, etc.Think of this as _"Cherry-picking a commit series"_ from text file(s) created by you or someone else.- # 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 came from something that is not Git.
- # `git apply`
- This applies a **delta** to your **worktree.** It's nominally a Git-flavored version of `patch`. It's more versatile than `git-am` but less powerful.
- _Think of this as **"Applying a `git stash`"** from a text file created by you or someone else._
- # `git am`
- This applies **commits** to your **`HEAD`.** It could be a single commit or a series of them, keeping the author, message, authordate, etc. It does require that the diff was generated by `git format-patch`, so it's less versatile than `git-apply`, but it's more powerful.
- _Think of this as **"Cherry-picking a commit range"** from text file(s) created by you or someone else._
- Several notable projects don't use public repos and pull requests for upstreaming code. Instead they share patches directly as these `format-patch` text files for the maintainer to apply and evaluate.
- # 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-patch`.
#1: Initial revision
by
Michael
·
2024-01-17T15:07:50Z (4 months ago)
# `git apply` This applies a **delta** to your **worktree.** It's nominally a Git-flavored version of `patch`. Think of this as _"Applying a `git stash`"_ from a text file created by you or someone else. # `git am` This applies **commits** to your **`HEAD`.** It could be a single commit or a series of them, keeping the author, message, authordate, etc. Think of this as _"Cherry-picking a commit series"_ from text file(s) created by you or someone else. # 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 came from something that is not Git.