[darcs-users] "don't pull this patch now or ever again"

David Roundy droundy at abridgegame.org
Fri Jul 30 09:08:24 UTC 2004

On Thu, Jul 29, 2004 at 10:26:30PM +0200, Juliusz Chroboczek wrote:
> > > So what are your plans?  Implementing the blacklist as a new type of
> > > patch that commutes with everyone and has the side-effect of
> > > inhibiting pulls of dependents?
> > No, it'd just be a list of patches never to pull.  Then the SelectPatches
> > routines would be told not to pull those patches, which would have the
> > result that one couldn't pull any patches that depend on them.
> So what happens if I do
>   darcs reject --patch-name 'Micro-optimise darcs reject'
>   darcs push
> ?
> I'd rather see a new patch type, so that all the mirrorring
> framework works as usual.

I guess it depends on what you want to do with the ffeature.  It seems to
me that you don't *want* the "ignore" information to go to anyone else.  I
suppose we could do like is done with test and boring, and let the setpref
command be used to make a version-controlled ignore file, but I'm thinking
that you are thinking something quite different from what I'm
thinking... and thus the confusion, perhaps.

What do you want

darcs reject --patch-name 'Micro-optimise darcs reject'

to do? Or to mean?

I was thinking more in terms of setting the ignore preferences during patch
select, somthing like

$ darcs pull
Thu Jul 29 14:15:05 EDT 2004  Frank Ruell <stoerte at dreamwarrior.net>
  * correct libcurl flags
Shall I pull this patch? (1/1) [yniWvxqdjk?] i
You don't want to pull any patches, and that's fine with me!
$ darcs pull
No remote changes to pull in! (Ignored 1 remote change)

i.e. it just indicates a patch you don't want to pull (or conversely send
or push).  But there's no reason why this would mean anyone else shouldn't
be able to pull that patch...

As far as applications, I would imagine using this to avoid pulling a patch
that introduces a bug on your platform (until you've heard that it's fixed)
or to avoiding private changes, like in my (private) "woody" darcs
repository where I keep the changes to debian/ needed to create darcs debs
for woody.  I could have my normal darcs directory ignore those when I pull
(so I could easily pull just bug fixes I might have made in that
directory).  But there's no reason for the entire world to have blacklisted
"woody 0.9.22".  It seems like if you try to put the blacklisting feature
into patches, then you'll have to start blacklisting your blacklist patches
and end up with a way-too-complex solution.
David Roundy

More information about the darcs-users mailing list