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. Thanks, Harris
> 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. https://wiki.debian.org/UsingQuilt http://www.shakthimaan.com/downloads/glv/quilt-tutorial/quilt-doc.pdf 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. https://nasamuffin.github.io/git/open-source/email/code-review/2019/05/22/how-i-learned-to-love-email-patches.html https://drewdevault.com/2018/07/02/Email-driven-git.html 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 patch. 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.