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

David Roundy droundy at darcs.net
Wed Aug 1 17:45:48 UTC 2007


On Wed, Aug 01, 2007 at 02:28:44AM +0200, Alexander Staubo wrote:
> 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. :)

It's probably no more fragile than what you're doing, possibly less
fragile, and has the advantage of using darcs' own code to do what it's
designed to do.

> 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.

If you want to do something with the XML format, you could ask for new
output to be added.  As I have mentioned, this is the only format darcs
generates that's intended to be parsed by external programs.

> [*] 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.

The first two are formatted so as to look friendly to humans.  The
indentation in changes -v is so that users can easily recognize the
boundaries between one change and the next.  The context format is darcs'
internal 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?

What do you mean by "changes to that"?

> > > 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.

I think this is really the solution you should use.  It's a bit tedious,
and could be thrown off by flags added to future versions of darcs, but
it's the way darcs is designed to work: any flag that's reasonable to
override (which doesn't include --disable, for instance) should have an
inverse flag.

You also might need to clear some environment variables, since they can
also affect darcs output formatting (particularly those related to
coloring).
-- 
David Roundy
Department of Physics
Oregon State University



More information about the darcs-users mailing list