[darcs-users] Getting a full diff for pulled patches

[Alexander Staubo]

On 8/1/07, David Roundy <droundy at darcs.net> wrote:
> On Wed, Aug 01, 2007 at 12:43:44AM +0200, Alexander Staubo wrote:
> > The only workaround I can think of is to run Darcs interactively, but
> > that complicates things awfully, and I would like to avoid it. My
> > intent is to warn the user: "You're pulling patch A. This requires
> > patch B. Do you want to continue?" As I think you pointed out, even if
> > I used the interactive prompt in conjunction with the "w" command, I
> > would not know when I had reached the last patch.
>
> You could actually compute the dependencies of the last patch by selecting
> 'n' for earlier patches and seeing which ones disable the last one.

Sounds tricky, but doable. For this first version I think I'll be lazy
-- not worry about dependencies at all, and simply let Darcs pull in
everything.

I did consider doing an initial pull pass with --no-deps to see which
patches had dependencies, but that seems to have no effect, or perhaps
I have misunderstood the meaning of this option:

$ darcs pull --no-deps --dry-run --matches='exact "A"'
Would pull the following changes:
Thu Jul 26 22:06:53 CEST 2007  Alexander Staubo <alex at purefiction.net>
  * B
Wed Aug  1 00:16:42 CEST 2007  Alexander Staubo <alex at purefiction.net>
  * A

Making no changes:  this is a dry run.

> > Given all of the above, I think two small improvements would be
> > enormously helpful:
> >
> > (1) Let "pull", "push", "changes" and possibly others print patch
> > hashes (in --verbose, perhaps).
>
> Sure.  The reason it's only in the XML output is because that's the only
> one that is designed for machine consumption.  Another approach would be to
> improve XML output so that you could use it effectively.
>
> Adding (optional) patch hashes to the --dry-run output would be fine,
> although I'd rather not have programs having to parse darcs' human-readable
> output.  That's just a fragile approach.  :(

And yet you are encouraging people to talk to Darcs' interactive
prompt from their programs. :)

I have spent a lot of time now driving Darcs from programs, and the
minimal support for this idiom makes it painful. The XML format is not
terribly useful to me since it doesn't provide diffs. Darcs uses at
least three vaguely different formats [*] to express patches, and my
parser must process all of them. Cleaning up and streamlining this
would be helpful.

[*] There's the normal "pull -v" format, there's the "changes -v"
format (same as pull, but indented for some reason) and there's the
context format.

> > (2) Add a flag to "pull" and possibly "changes" that included the
> > patch context in the output. I believe this would be sufficient to
> > determine dependencies.
>
> I'm not sure what you mean by the "patch context."  In standard darcs
> terminology, this would mean the set of all preceding patches, which is
> pretty obvious in darcs changes, and also completely useless with regard to
> determining dependencies.

Yeah, I just realized this. Change that to mean dependencies, then. Possible?

> > Lastly: Does Darcs have a way to disable the loading of one's personal
> > defaults file, akin to CVS' -f ("Do not use the ~/.cvsrc file.") flag?
>
> No, that's a reasonable idea, although then we might also need a way to
> disable the disabling of the defaults file, since one possible use of
> defaults is to lock down a repository (e.g. using --disable to disallow
> certain dangerous commands, and making defaults not be modifiable by
> users).  It's not a particularly pretty or powerful approach to security,
> but we also don't want to silently dismantle our users' security
> mechanisms.

Yep. Well, the intent here is to ensure that Darcs starts with a clean
slate insofaras it makes Darcs predictable and produces consistently
parsable output.

On the other hand, disabling *all* defaults would be
counter-productive, since some options (like the SSH control master
stuff) must be usable even when Darcs is being invoked
programmatically.

So it's a bit more complicated than I thought. I don't even have a
full picture at the moment of what options need to be reset.

It works fine at the moment because I pass things like --no-test,
--no-summary and --no-set-default when I need to ensure such
behaviour; most behaviour-modifying options have an inverse
counterpart that I can apply.

Alexander.