I would like to create a patch from a specific gcc branch comparing it to the official releases; so when I unpack the tarball from the stable release, I can apply the patch and get the equivalent of what was in that specific branch .

It's the first time I need to create a patch, so it's my very first time doing this and my main concern is to get the options and the parsing right since we are talking about an extremely important piece of software

diff -crB GccStable GccGit > /tmp/fromStabletoBranch.patch

Is this enough and the best way of doing it ?

  • The usual good practices here involve version control or some variant of these. This includes, mercurial, git, and their associated patch queue extensions. You could also consider quilt. Perhaps you could go into more detail as to what you are trying to do? Oct 14, 2014 at 21:46
  • @FaheemMitha what do you mean with "more details" ? I have a version of gcc from the official stable tar.bz2 and another unstable version of it from a git repository, I would like to create a patch, of course I would like to compare just against the master branch, not the entire repository . Oct 14, 2014 at 21:50
  • OK, well, sure you can use something as simple as diff. but using version control is generally preferable. For one thing, it makes it much harder to lose track of what you are doing. Oct 14, 2014 at 21:57
  • @FaheemMitha I don't understand what you are suggesting, my tar.bz2 is clearly not a git repository, how do you think I should proceed ? Oct 14, 2014 at 22:01
  • 1
    Do a search for "creating patches using version control". Two previous answers I've written which are related are unix.stackexchange.com/a/127810 and unix.stackexchange.com/a/139817 Oct 15, 2014 at 8:43

2 Answers 2


Yes, this is a good way to create a patch.

In short:

  1. To create patch for single file your command may look like

    diff -Naru file_original file_updated > file.patch


    • -N: treat absent files as empty
    • -a: treat all files as text
    • -r: recursively compare any subdirectories found
    • -u: output NUM (default 3) lines of unified context
  2. To create patch for whole directory:

    diff -crB dir_original dir_updated > dfile.patch


    • -c: output NUM (default 3) lines of copied context
    • -r: recursively compare any subdirectories
    • -B: ignore changes whose lines are all blank

After all to apply this patch one can run

patch -p1 --dry-run < dfile.patch

where switch p instructs patch to strip the path prefix so that files will be identified correctly. In most cases it should be 1.

Remove --dry-run if you are happy from the result printed on the screen.

  • question: what is supposed to happen if a directory or a file gets deleted in the dir_updated compared to what there was in dir_original ? The diff takes care of that too or it gets skipped ? Oct 15, 2014 at 7:47
  • @user2485710 diff sees which files were deleted. file.patch in just a text file, so you can open it in any editor or just cat it and you will see a line like only in dir_original: missingfile.txt
    – jimmij
    Oct 15, 2014 at 14:51
  • ok, but then patch will delete that missingfile.txt or what else ? Oct 15, 2014 at 15:14
  • It depends. If you want to remove them use diff -N ... as in my first example. Normally patch will remove empty files by default. If you don't want, just use only diff -crB as in your question. Also in some (rare) cases -E option in patch command is needed to remove empty files, after patch manual: if the input is not a context diff or if patch is conforming to POSIX, patch does not remove empty patched files unless this option is given
    – jimmij
    Oct 15, 2014 at 15:33
  • i've run diff -Naru dir/file dir/file.new > diff.patch getting can't find file to patch at input line 3 with patch -p0 --dry-run < diff.patch first line of patch reads --- dir/file second one +++ dir/file.new with timestamps, the diff seems to be just right, is there any option how report the exact filenames the command looks for?
    – ptica
    Mar 14, 2019 at 11:57

If you want to compare latest git checkin to some stable version, just go git diff the-stable-version (will need to figure out what tag describes it, probably the exact version number or some variant) in the repository. git keeps the full history of the project (normally, there are ways to grab just a part). It doesn't matter if the-stable-version is in some different development branch (i.e., the development forked off and the stable branch got some last-minute fixes).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .