JaroslavTulach: /* Trying It */ - 2026-01-21 06:24:04

Trying It

←Older revision Revision as of 06:24, 21 January 2026
Line 53: Line 53:
The '''-p''' argument is very important. Without it [[patch]] command doesn't know how to interpret the header and locate the ''Channel.java'' file. In such case the [[patch]] command switches to interactive mode - which is quite annoying (but it shows how old the [[patch]] command is - it comes from ages when interactions with user were happening in terminal and not a [[GUI]]). Using '''-p''' argument avoids the interactivity.
The '''-p''' argument is very important. Without it [[patch]] command doesn't know how to interpret the header and locate the ''Channel.java'' file. In such case the [[patch]] command switches to interactive mode - which is quite annoying (but it shows how old the [[patch]] command is - it comes from ages when interactions with user were happening in terminal and not a [[GUI]]). Using '''-p''' argument avoids the interactivity.
 +
 +
With '''-p0''' the above patch seeks for ''channels/Channel.java'' file. One can use '''-p1''' to instruct [[patch]] utility to strip one level from the specified directories. Then the utility would be looking for ''Channel.java'' file only. By default use '''-p1''' for diffs generated by [[git]] '''diff''' command.
=== Pipe It! ===
=== Pipe It! ===

JaroslavTulach at 06:20, 21 January 2026 - 2026-01-21 06:20:44

←Older revision Revision as of 06:20, 21 January 2026
Line 23: Line 23:
</source>
</source>
-
=== Quiz ===
+
== Quiz ==
What do you think about the above text?
What do you think about the above text?
Line 36: Line 36:
* I know the '''-R''' argument of the CLI command
* I know the '''-R''' argument of the CLI command
* I know something more than [[I|you]]!
* I know something more than [[I|you]]!
 +
 +
 +
== Answers ==
=== Reading ===
=== Reading ===

JaroslavTulach: /* Trying It */ - 2026-01-21 06:19:52

Trying It

←Older revision Revision as of 06:19, 21 January 2026
Line 50: Line 50:
The '''-p''' argument is very important. Without it [[patch]] command doesn't know how to interpret the header and locate the ''Channel.java'' file. In such case the [[patch]] command switches to interactive mode - which is quite annoying (but it shows how old the [[patch]] command is - it comes from ages when interactions with user were happening in terminal and not a [[GUI]]). Using '''-p''' argument avoids the interactivity.
The '''-p''' argument is very important. Without it [[patch]] command doesn't know how to interpret the header and locate the ''Channel.java'' file. In such case the [[patch]] command switches to interactive mode - which is quite annoying (but it shows how old the [[patch]] command is - it comes from ages when interactions with user were happening in terminal and not a [[GUI]]). Using '''-p''' argument avoids the interactivity.
 +
 +
=== Pipe It! ===
 +
 +
The [[patch]] command expects the changes on stdio - hence the '''<''' to send ''my.diff'' file in. That can be useful to ''cherry pick'' any [[git]] commit. Just try:
 +
<source lang="bash">
 +
$ git show 88e601f | patch -p1
 +
</source>
 +
and the changes from ''88e601f'' commit will be applied just like you'd typed them manually. Simple way to extract changes from [[git]] history without [[git]] knowing anything about it - e.g. without changing the internals of the local [[git]] repository at all.
=== Embeddable Format ===
=== Embeddable Format ===

JaroslavTulach: /* Applying a PR from Another GitHub Repository */ - 2026-01-21 06:10:20

Applying a PR from Another GitHub Repository

←Older revision Revision as of 06:10, 21 January 2026
Line 56: Line 56:
=== Applying a PR from Another GitHub Repository ===
=== Applying a PR from Another GitHub Repository ===
 +
 +
A neat trick is to feed [[patch]] directly from GitHub. Did you know each pull request URL can be appended with ''.diff'' or ''.patch'' and then one gets a plain text page in [[patch]] format? As such one can:
<source lang="bash">
<source lang="bash">
Line 61: Line 63:
</source>
</source>
 +
Get all changes in 14666 PR and pipe the output directly to [[patch]] utility. Don't forget to remove one directory from paths (as by default [[Git]]'s prepends '''a''' and '''b''' to differentiate between original and target file) by applying '''-p1'''.
== Conclusion ==
== Conclusion ==
I have been adding (sometimes complicated) diffs as PR comments for many years and just recently I realized that I am not sure people know how to apply them! That's why I decided to write this down. I find the [[patch]] command line utility very useful. I wish its knowledge would spread. Let this little quiz help with that!
I have been adding (sometimes complicated) diffs as PR comments for many years and just recently I realized that I am not sure people know how to apply them! That's why I decided to write this down. I find the [[patch]] command line utility very useful. I wish its knowledge would spread. Let this little quiz help with that!

JaroslavTulach at 05:45, 21 January 2026 - 2026-01-21 05:45:36

←Older revision Revision as of 05:45, 21 January 2026
Line 60: Line 60:
$ curl -L https://github.com/enso-org/enso/pull/14666.diff | patch -p1
$ curl -L https://github.com/enso-org/enso/pull/14666.diff | patch -p1
</source>
</source>
 +
 +
 +
== Conclusion ==
 +
 +
I have been adding (sometimes complicated) diffs as PR comments for many years and just recently I realized that I am not sure people know how to apply them! That's why I decided to write this down. I find the [[patch]] command line utility very useful. I wish its knowledge would spread. Let this little quiz help with that!

JaroslavTulach: /* Embeddable Format */ - 2026-01-21 05:41:32

Embeddable Format

←Older revision Revision as of 05:41, 21 January 2026
Line 54: Line 54:
The above [[diff]] format can be easily embedded into an email and sent as a ''part of a message''. E.g. surrounding the [[patch]] with prose sections as completely OK. The [[patch]] command line tool will just ignore everything not having the appropriate '''diff''' header
The above [[diff]] format can be easily embedded into an email and sent as a ''part of a message''. E.g. surrounding the [[patch]] with prose sections as completely OK. The [[patch]] command line tool will just ignore everything not having the appropriate '''diff''' header
 +
 +
=== Applying a PR from Another GitHub Repository ===
 +
 +
<source lang="bash">
 +
$ curl -L https://github.com/enso-org/enso/pull/14666.diff | patch -p1
 +
</source>

JaroslavTulach: /* Quiz */ - 2026-01-21 05:37:31

Quiz

←Older revision Revision as of 05:37, 21 January 2026
Line 36: Line 36:
* I know the '''-R''' argument of the CLI command
* I know the '''-R''' argument of the CLI command
* I know something more than [[I|you]]!
* I know something more than [[I|you]]!
 +
 +
=== Reading ===
 +
 +
My colleague Ilya wrote: ''" In most cases, I will just observe the patch without applying it if it is small enough. (it usually is!)"''. In such case the situation is simple. Lines starting with a single '''-''' are the ones being removed and those starting with a single '''+''' are those being added. The header identifies the file that's being modified, but one doesn't really have to parse it - it is clear the above [[patch]] is related to ''Channel.java'' file.
 +
 +
=== Trying It ===
 +
 +
However sometimes just reading isn't enough. Sometimes we need to apply the [[patch]] locally to try how it behaves. Let's quote Ilya one more time: ''"If it is small enough (a few lines), I will repeat it manually, if ... typing everything by hand is not an option, I will apply it with [[git]]."'' [[I]] am not fully sure how to apply a [[patch]] with [[git]], but let's do it with another program (years older than [[git]]) which is (unsuprisingly) named [[patch]].
 +
 +
<source lang="bash">
 +
$ patch -p0 <my.diff
 +
</source>
 +
 +
The '''-p''' argument is very important. Without it [[patch]] command doesn't know how to interpret the header and locate the ''Channel.java'' file. In such case the [[patch]] command switches to interactive mode - which is quite annoying (but it shows how old the [[patch]] command is - it comes from ages when interactions with user were happening in terminal and not a [[GUI]]). Using '''-p''' argument avoids the interactivity.
=== Embeddable Format ===
=== Embeddable Format ===
The above [[diff]] format can be easily embedded into an email and sent as a ''part of a message''. E.g. surrounding the [[patch]] with prose sections as completely OK. The [[patch]] command line tool will just ignore everything not having the appropriate '''diff''' header
The above [[diff]] format can be easily embedded into an email and sent as a ''part of a message''. E.g. surrounding the [[patch]] with prose sections as completely OK. The [[patch]] command line tool will just ignore everything not having the appropriate '''diff''' header

JaroslavTulach at 08:02, 20 January 2026 - 2026-01-20 08:02:11

←Older revision Revision as of 08:02, 20 January 2026
Line 36: Line 36:
* I know the '''-R''' argument of the CLI command
* I know the '''-R''' argument of the CLI command
* I know something more than [[I|you]]!
* I know something more than [[I|you]]!
 +
 +
=== Embeddable Format ===
 +
 +
The above [[diff]] format can be easily embedded into an email and sent as a ''part of a message''. E.g. surrounding the [[patch]] with prose sections as completely OK. The [[patch]] command line tool will just ignore everything not having the appropriate '''diff''' header

JaroslavTulach at 07:59, 20 January 2026 - 2026-01-20 07:59:27

←Older revision Revision as of 07:59, 20 January 2026
Line 1: Line 1:
-
How can a [[path]] be distributed? When accepting [[API Patch]]es and having proper [[Git]] repository infrastructure one can probably think of a [[patch]] as a pull request. However, there are older and [[I]]'d like to claim still useful ways to deliver patches that work well with [[Git]] and other versioning systems. In fact this ''old [[good]] way'' is still in the heart of these versioning systems. [[I]] am talking about:
+
How can a [[patch]] be distributed? When accepting [[API Patch]]es and having proper [[Git]] repository infrastructure one can probably think of a [[patch]] as a pull request. However, there are older and [[I]]'d like to claim still useful ways to deliver patches that work well with [[Git]] and other versioning systems. In fact this ''old [[good]] way'' is still in the heart of these versioning systems. [[I]] am talking about:
<source lang="diff">
<source lang="diff">

JaroslavTulach at 07:59, 20 January 2026 - 2026-01-20 07:59:18

←Older revision Revision as of 07:59, 20 January 2026
Line 1: Line 1:
-
What's a [[patch]]? How can it be distributed? When accepting [[API Patch]]es one can probably think of a [[patch]] as a pull request. However, there are older and [[I]]'d like to claim still useful ways to deliver patches that work well with [[Git]] and other versioning systems. In fact this ''old [[good]] way'' is still in the heart of these versioning systems. [[I]] am talking about:
+
How can a [[path]] be distributed? When accepting [[API Patch]]es and having proper [[Git]] repository infrastructure one can probably think of a [[patch]] as a pull request. However, there are older and [[I]]'d like to claim still useful ways to deliver patches that work well with [[Git]] and other versioning systems. In fact this ''old [[good]] way'' is still in the heart of these versioning systems. [[I]] am talking about:
<source lang="diff">
<source lang="diff">