w64devkit, and patch based version control

Harris Snyder
Message ID
DKIM signature
Download raw message
Hi Chris,

I love w64devkit, thank you very much for putting it together. I'm
curious if you have any tips on using patch and diff effectively to
manage source code, perhaps in the context of a small team (2-3
people)? I have always used git, so I don't have much experience with
trying to collaborate without it, but I'm curious if there are any
common tricks for managing a patch based workflow?

If you do have any ideas on this, I think it might be beneficial to
add them to the w64devkit tutorial article if you have the time :). I
imagine other people might have the same question.

Message ID
<CAKF5_TnNbyawoQQXvMN7gMTOKAUrtBwu8zoQ_tHP-4pJzESTgg@mail.gmail.com> (view parent)
DKIM signature
Download raw message
> I'm curious if you have any tips on using patch and diff effectively to 
> manage source code, perhaps in the context of a small team (2-3 people)?

Quilt can serve as a practical example of what to do. It's a collection of 
scripts for patch-based workflows, predating Git. It essentially automates 
all the otherwise-manual work of running diff and patch yourself.


Even in a world dominated by Git, Quilt still has its uses. Unlike Git, 
it's great for maintaining an independent, local patchset on top of an 
upstream code base. StGit attempts to be the best of both, being like Git 
where you need Git and like Quilt where you need Quilt, and studying it 
can provide similar hints about patch-oriented workflows.

Studying Git-based email patch workflows should give you some ideas, too. 
In these workflows, commits are initially transmitted as patches rather 
than pushed / pulled directly from a remote Git repository, and so Git is 
really just a fancy tool for preparing patches, much like Quilt.


With Git currently off the table, I'd love to simply include Quilt itself 
in w64devkit. Unfortunately it's written in Bash with a bit of Perl, so 
it's also not practical. However since diff and patch are part of BusyBox 
you can still accomplish nearly all the same things without it, albeit 
more tediously.

> If you do have any ideas on this, I think it might be beneficial to add 
> them to the w64devkit tutorial article if you have the time :)

Good idea, Harris! I'll start with a first draft of sorts here.

Without Quilt or any fancy tooling over diff and patch, you would have a 
pristine copy of the source sitting adjacent to your working directory. 
Git names the pristine copy "a" and the updated copy "b" in its patches, 
and I generally follow suit. So for instance, suppose you're working on 
fixing a bug in Foo 1.2.3:

tar xzf foo-1.2.3.tar.gz
mv foo-1.2.3 a
cp -r a b

You make your changes in b, and to check how things are going you run diff 
from the same root directory:

diff -pruN a b >bugfix.patch

The -p annotates hunks with the function name, -r is for recursive, -u is 
for the unified diff format, and -N uses the Git convention for new files. 
All these options together produces something much like a Git patch, and 
this patch is ultimately what you share / publish. How you share it is 
another issue, and one you'd need to sort out with your team. :-) Normally 
you'd inline it in an email sent to a mailing list, but w64devkit does not 
include mail tools or anything to streamline this, as would be the case on 
a real unix system.

However they receive it, the recipient ultimately applies the patch using 
patch. The "-p1" option is the most common way to run it, and it tells 
patch to strip away 1 directly level (i.e. the "a/" and "b/") from all 
file paths:

patch -p1 <bugfix.patch

There's also an -R option to reverse a patch, to unapply it. So someone 
could apply it, try it out, and unapply it to go back to their initial 
state, kind of like switching branches in Git. Similarly, you could squash 
patches by applying several of them then using diff to produce a whole new 

You can edit the patch with your text editor and insert (almost) whatever 
contents you want at the top of the patch file. The patch program will 
ignore these contents since they don't look like a diff. This is the 
equivalent to a commit message where you can describe the purpose of the 
patch. Often this will include mail headers and so a patch file is 
simultaneously patch and email message.

Your team's integration manager, merge master, etc. would gather up all 
the accepted patches, apply them to the Foo 1.2.3 tarball, maybe write up 
a changelog about the patches, then make a new release with the patches 
applied. (This is how, for instance, Linux kernel development worked for 
years, and still mostly how it works.) Everyone gets the new tarball and 
develops their patches against the new release. They also might need to 
update pending patches, though in most cases they'll still apply correctly 
thanks to patch fuzzing. (This is where tools like Quilt can be a great 
help since they can "refresh" patches to a new context very easily.)

I haven't personally worked this way very much, and not beyond a team of 
two. When I dogfood w64devkit I usually do so on a pristine system with no 
other tools installed, not even Git. To make changes to my own programs in 
this environment — such as when I port a program from Linux to Windows via 
w64devkit — I'll start from a source tarball downloaded from GitHub, make 
my changes, produce patches per above, then send the patches back over to 
my primary Linux system in order to convert into Git commits that I can 
push to GitHub.

Hopefully that provides some hints on how to get by without Git! I'm not 
claiming this is all *better* than Git or anything like that. It's just 
another way to collaborate.
Reply to thread Export thread (mbox)