[darcs-users] reviewing and testing pulls

[Andrew Pimlott]

On Wed, Apr 28, 2004 at 07:48:14AM -0400, David Roundy wrote:
> On Tue, Apr 27, 2004 at 11:47:10AM -0400, Andrew Pimlott wrote:
> > If I understand what you're proposing, the problem with this is that the
> > hunks would still be divided among multiple patches.  If multiple patches
> > touch one file, I'd like to see the cumulative change.  This is why I
> > said that the human-readable form of send doesn't have to be suitable for
> > applying the patches.
> 
> I've just now gotten around to adding the -u option to send, by the way.

cool

> Hmmm.  So your concern is that when multiple patches are sent which modify
> the same file, each modification is displayed in order, which could be
> confusing/hard to read.
> 
> I would contend that if darcs (or any other SCM) is used *properly*
> (properly here being an aesthetic distinction) it should be easier to view
> the changes separately.

Perhaps you're right.  Experience will tell.

Even given this, the fine granularity of darcs
hunks makes it awkward to read:

    hunk ./foo 1
     a
     b
     c
    -a
    +1
     b
     c

    hunk ./foo 3
     1
     b
     c
    -c
    +3

> That way each change has its name and comments
> along with it so you can see what each change was intended to do.  As long
> as the names are useful and the patches are self-contained (e.g. not a
> string of "oops" patches for a single change)

Not all that uncommon.  :-)

> > Would it be feasible to unpull back to a tag?  Right now, unpull
> > option.  But if I could unpull to a tag, I'd just tag, pull, and unpull
> > to the tag to reject.
> 
> Hmmmm.  It is certainly doable, but a bit scary (what if you mistype the
> tag?).

It could show you a list of all the patches that would be unpulled with
the tag and prompt before proceeding.

> You can also accomplish this with a darcs get --tag-name followed
> by a directory delete and rename.  On the other hand, this doesn't have
> much of an advantage over just doing the pull into a temporary repo in the
> first place.

As much as I like the "branches are cheap" philosophy, I still don't
think it fits this task well.  The process (apply patches, review and
test, accept or reject) is linear, and I think darcs should support it
in a linear way.  Especialy (as another poster suggested) if you will
usually be keeping the patch set, and only rarely backing it out.

Andrew