On Mon, 22 Oct 2007, David Glasser wrote:
> On 10/22/07, Charles Acknin <charlesacknin@gmail.com> wrote:
> > On 10/22/07, Daniel L. Rall <dlr@finemaltcoding.com> wrote:
> > > > Ugh :-(. That's a tough one. The simplest answer for now might be to
> > > > notice whether there were copies/moves during the dry run, trap the
> > > > error from the external patch program, see if the error applies to any
> > > > of the putatively copied/moved items, and transform it into an
> > > > "application deferred" warning instead. I realize that's lame, but
> > > > it's the best I can come up with right now.
> > >
> > > This is a similar approach to what we use for dry-run merges. It's lame,
> > > but better than nothing.
> >
> > That sounds very tricky. For example, GNU patch prompts the user for
> > a direction to take when such thing happen. Does that mean we're also
> > going to wrap the program's input stream and answer on behalf of the
> > user when the prompting questions match a particular pattern? That
> > sounds like a lot of code specific to one external program and again
> > very hairy.
> >
> > How about temporarily spawning the files the external tool needs for
> > the time it runs? That could involve spawning a whole tree.
>
> Writing to the wc during --dry-run seems like a bad idea. I'd rather
> drop dry-run functionality than need to do this. (In fact in the
> interest of actually finishing this increasingly hairy feature, maybe
> you should punt --dry-run until later?)
That sounds okay to me, too (I had actually been thinking the same thing).
- application/pgp-signature attachment: stored
Received on Tue Oct 23 20:06:52 2007