Sometimes it would be nice to be able to "ban" certain patches from
upstream. That is, 'pull' shouldn't ask for banned patches to be pulled
(or pull them with -a) unless they have newer dependencies. The obvious
interface to do this banning is a new option to the pull query.

> Sometimes it would be nice to be able to "ban" certain patches from
> upstream. That is, 'pull' shouldn't ask for banned patches to be pulled
> (or pull them with -a) unless they have newer dependencies. The obvious
> interface to do this banning is a new option to the pull query.

This is the same as http://otherbugs.darcs.net/index.html?q=37 but
it's not a bad idea to
have a version in the new bugtracker.

I did create an initial patch for this a while back, but it needs a lot of work.

> Sometimes it would be nice to be able to "ban" certain patches from
> upstream. That is, 'pull' shouldn't ask for banned patches to be pulled
> (or pull them with -a) unless they have newer dependencies. The obvious
> interface to do this banning is a new option to the pull query.

Should bans/refusals propagate?

In other words: if you ban a given patch, and I pull from you, do I
automatically get to ban that patch?

                                        Juliusz

> > Sometimes it would be nice to be able to "ban" certain patches from
> > upstream. That is, 'pull' shouldn't ask for banned patches to be pulled
> > (or pull them with -a) unless they have newer dependencies. The obvious
> > interface to do this banning is a new option to the pull query.
>
> Should bans/refusals propagate?
>
> In other words: if you ban a given patch, and I pull from you, do I
> automatically get to ban that patch?

I think it would be best to always manually add bans.  So I could pull
in a banned patch and then immediate ban it, if I'd like.  I wonder if
the user should be notified that the patch was banned on the other
side, though.  I'm not sure if a user would care that it was banned in
the remote repository.

This is an often requested feature.  It will doubtless happen at some point.

Oh, and there's no doubt that patches to do that will be gratefully accepted.

Would a notion of local patches be good enough, or would we need both local
patches and banned patches?

Banned patches: "don't ever pull these patches from the other guy"
Local patches: "don't let anybody pull/get these patches; don't push them either"

Should local patches become a separate feature request?

Incidentally, I suppose if you make patches which depend on local patches, then
they too become local.

Both "banned" and "local" patches seem interesting to me too, but I haven't
thought through what the implications might be.

if we implement local patches, use of amend-record would be made very handy by
having the following:
-make record produce local patches by default
-make record be --no-test by default
-add a bless command which (optionally) runs the tests and makes the patch non-local
-make a commit command which offers to either create a new patch (ie use
record), or amend one of the local patches.

> if we implement local patches, use of amend-record would be made very handy by
> having the following:
> -make record produce local patches by default
> -make record be --no-test by default
> -add a bless command which (optionally) runs the tests and makes the patch non-local
> -make a commit command which offers to either create a new patch (ie use
> record), or amend one of the local patches.

I'm not yet comfortable with changing the standard darcs flow. I'm
particullary not comfortable with adding a "commit" command, which
people will expect to work like "commit" in CVS, SVN or "git".

For me, a "local" patch remains an uncommon case, so I would prefer
that the interface require something extra to generate one, rather than
make it the default behavior.

    Mark

On 2009-01-09 15:17 -0000, Mark Stosberg wrote:
> For me, a "local" patch remains an uncommon case, so I would prefer
> that the interface require something extra to generate one, rather than
> make it the default behavior.

at all, although I presume this is a rarer case. (Uou should probably
just have multiple working copies then, creating new public ones in 
one that doesn't have any "local" patches). A somewhat more common 
case is probably that you don't want to pull some patches from a
public/upstream repository, and don't want to be asked about it
every time you pull something else. So I think the interface should
be an option to the interactive pull interface (and for the other 
case, if supported, push) to ban the patch.

Hmm.. the bug tracker or something seems to have dropped the first 
two lines from my comment. (There's a perfectly good saved local copy.)
They should have been:

> There are two ways a patch can be local/banned: for push or for pull.
> From your working copy, you may not want to push particular patches

Note: I've split the request for local patches off into issue1543.

I claim that this has been resolved actually quite a long time ago by this patch

Sun Feb  4 18:13:01 GMT 2007  Kevin Quick <quick@sparq.org>
  * Added --complement to pull to allow "exclusion" repos

With this you can pull the banned patches into a 'banned' repo and then do

  darcs pull --complement main banned

Feel free to argue that this isn't really what you wanted and re-open :-)

It may need to be an FAQ to be more discoverable.