When doing darcs rollback and the user intendes to rollback a rather
patch that is behind a tag the UI is rather confusing.

The UI misleadingly indicates that the tags will be rolled back too.
This is not what the user wants to do. The user wants to roll back
just the old patch and to leave all the tags alone.

In fact the tags are not rolled back, it is just the UI that gives
this misleading impression.

Example:  (this is in the Cabal repo)

$ darcs-2.7.3 rollback -p '(now in separate repos)'
Sun Oct 10 16:50:50 BST 2010  Duncan Coutts <duncan@haskell.org>
  tagged 1.10 branch forked
Shall I rollback this patch? (1/13)  [ynW...], or ? for more options: n
Will not ask whether to rollback 12 already decided patches.
No patches selected!

So I select a patch with -p that I want to rollback, and it offers me
a tag. I don't want to rollback any tags so I say 'n'. darcs then
tells me that there are no patches, selected, ie the patch that I want
to rollback depend on me also rolling back all these tags. That's not
what I want to do!

I try it anyway:

$ darcs-2.7.3 rollback -p '(now in separate repos)'
Sun Oct 10 16:50:50 BST 2010  Duncan Coutts <duncan@haskell.org>
  tagged 1.10 branch forked
Shall I rollback this patch? (1/13)  [ynW...], or ? for more options: w
[... repeat 12 times ...]
Thu Apr  5 20:47:29 BST 2007  Ian Lynagh <igloo@earth.li>
  * Remove cabal-{builder,install,setup,upload} (now in separate repos)
Shall I rollback this patch? (13/13)  [ynW...], or ? for more options: y
[...snip...]
Shall I rollback this change? (1/110)  [ynW...], or ? for more options: a
What is the patch name? Don't delete cabal-install from the cabal repo
Do you want to add a long comment? [yn]y

Now the message in the editor for the long comment lists all these
tags, again giving the impression that they are being rolled back:

Sun Mar  6 18:19:42 GMT 2011  Duncan Coutts <duncan@community.haskell.org>
  * Don't delete cabal-install from the cabal repo
  This is in preparation to merging cabal and cabal-install back into one repo

  rolling back:

  Thu Apr  5 20:47:29 BST 2007  Ian Lynagh <igloo@earth.li>
    * Remove cabal-{builder,install,setup,upload} (now in separate repos)

      R ./cabal-install/
      [..snip..]

  Fri Jun 29 12:25:45 BST 2007  Ian Lynagh <igloo@earth.li>
    tagged 2007-06-29

  [..etc another 10 tags that look like they're rolled back...]

  Sun Oct 10 16:50:50 BST 2010  Duncan Coutts <duncan@haskell.org>
    tagged 1.10 branch forked


So I think I've messed things up by rolling back all these tags, but
now I run darcs show tags and lo..

$ darcs show tags
1.10 branch forked
2009-06-25
1.6.0.1
1.6.0.0
6.10 branch has been forked
1.5.5
2008-05-28
1.5.1
1.3.9
2007-09-06
1.2.0
2007-06-29

They're all there!

So actually despite my dire expectations, this operation has done
exactly what I wanted!

So, how could the UI be improved here. Do we need to prompt users for
tags at all? Can tags even be rolled back? From my point of view as a
naive user I would not expect to be prompted to rollback any tags that
depend on the patch I want to roll back and I would not expect them to
be listed in the commit message.

I understand why when doing unrecord say, we have to also select all
the patches that depend on the one I want. But for rollback, we're
making a new patch on the top of the pile so I don't see how tag
dependencies come into it.

Duncan

Hi Duncan,

This is an interesting problem (not quite issue1241 but related).  Here 
the confusing elements are

- if rollback has the magical stop-at-tag behaviour in darcs obliterate 
(which I think has gone away recently), issue1241
- how rollback should behave wrt to tags and ask-deps [this may be new], 
since these virtual dependencies don't actually affect the physical 
reality of creating an inverse patch, it seems silly to respect them
- rolling back a tag has no effect - so should we adapt the UI to cater 
to this fact, maybe telling you we've passed the tag but not making a 
choice of it?

Maybe this is something darcs hackers can talk about during the 2011-04 
sprint 

 - issue1241
We need to talk about this some more

I think the current behaviour is okay *if* documented properly (I am not
sure whether it is). The logic is that you say 'w' to all patches you do
not want to rollback, but *might* want to, if necessary. Then darcs will
include (just) the changes in those patches that depend on the ones you
choose with 'y'. In case of a tag, this is never the case, but IMO it
still makes sense to let the user know that the stuff he rolls back is
behind a tag (so he can decide whether he wants that).

To make more precise what I wanted to say: A tag contains no *changes*
that depend on other changes in the repo. The tag itself, as a patch, of
course depends on other patches. Darcs rollback operates on individual
changes (hunks, file adds etc), not on patches. In principle, darcs
rollback could offer you all changes directly without mentioning patches
and their names (and w/o mentioning tags), but that would make it very
tedious to find the one you want to roll back.