Given a patch hash, e.g.
hash = 20100315093256-12142-a516943c813e404e0fb11d85e68131fb5e823e2f.gz
with old-fashioned repositories we could make a URL to the patch with
but this doesn't work with the hashed (or darcs2) format.
Can you please add a command, e.g. "darcs show patch filename", so we
can use e.g.
.../_darcs/patches/`darcs show patch filename -p $hash`
(regardless of repo format)
This shouldn't be too difficult to do for somebody to do. I would
recommend working on at least one other ProbablyEasy bug though.
It's probably a good idea to call it something else, or maybe make a
darcs show patch and add a flag for concise/quiet output?
Alternatively, we could make darcs show patch display the filename and
darcs show patch --verbose display the patch contents (eww, that seems a
Two other notes: you may need to be prepared for a UI discussion on this
on the list. I would suggest implementing one of the options below (or
something better), and only then start the discussion:
- darcs show patch filename (introduces a precedent of sub^N-commands;
needs modifications to the command line parsing)
- darcs show patch --quiet (seems a little yucky to overload quiet in
- darcs show filehash (shows the file contents hash for *any* object:
darcs show hash src/foo.c and darcs show hash -p bar might do different
- darcs show patch (shows the file contents hash followed by the patch
contents, so darcs show patch | head -n 1 would do what Ian wants)
Also, one documentation point you will want to make is that the command
is repository-local, in the sense that if you run this command in a
repository where the patch has been commuted to a different
representation, you'll get a different result.
Steve Keuschel was working on this during the 2010-03 sprint. We went
through several iterations of the UI. On Sunday, I finally suggested
that maybe it makes sense to put it in darcs changes --xml after all (so
In the past I had argued against doing this, but what made me changed my
mind is the fact that we show the patch contents, which change during
commutation anyway. So I now consider this to be a duplicate of the
previously wont-fixed issue859