Things I would use a hypothetical darcs rebase for.  This would clearly be an
unsafe command in the sense of darcs-amend, but I think we can come up with
enough scenarios to demonstrate that such a command would be useful in practice
(and used often enough to not want to do by hand).

Note, that I do not actually know what git rebase does; I've just heard vague
rumours about it.  Ganesh has called it 'amend-record on steroids', I think.

Also, this need to be necessarily be one single command.

 * Something went horribly wrong (due to a bug an older version of darcs, for
example) and I need to revise my patch history, replacing one of the patches in
the middle with something else (e.g. http://bugs.darcs.net/issue857 )

 * I made an unwise decision in the past to add a 40G binary file to my
repository and then changed my mind removing it.  I really do not need this in
the history, so I would like the file to really just go away

 * There is a bunch of patches I made that I would like to consolidate [can
actually be met by darcs unrecord and darcs record]

 * Somebody submitted a tarball of a repository for forensics, and I want to
simplify it.

 * I have a horribly conflicted repository that darcs cannot handle, but I want
to edit away some unwise conflict fighting that I did

Please submit any other unique scenarios you can come up with, as well as
user-interface ideas.

Oh, and the scenario that prompted this in the first place.

 * I created a darcs repository on top of somebody's source tarball, and now
I've gotten access to the original CVS repository which I can convert via
tailor.  Now I want my new patches to apply on top of the converted repository.
 (This is actually fairly easy to do with darcs send and by editing the patch
bundle, come to think of it)

Maybe the darcs rebase "command" could just consist of a wiki page showing
people how to edit patch bundles in a sensible manner.

Another thing to consider in this category is apply --ignore-context

I would not call anything in darcs rebase.  Ganesh may call git rebase
"amend-record on steroids", but I'd call it "a poor implementation of darcs for
git".  Basically, all it is is an implementation of commutation for a system
that doesn't properly support it.

My intended uses for a "rebase" command are as follows:

(1) In a darcs 1 repo, you are being killed by exponential merging.

(2) You need to clean up your history. There are several sub-reasons for this:
  (a) aesthetic reasons only
  (b) you want to submit to a project that wants nice-looking patches. I get the
impression from watching darcs-users that darcs itself is one such project, but
perhaps I'm wrong.
  (c) a conflict somewhere in that history is causing hassle during merges

Rebase is a workaround for cases where commutation doesn't do enough, as well as
(in git's case) where you don't have commutation at all.

Just sketching out possible darcs transplant UI (as a way for us to do some
thinking about what we want this command to do)

We could have three repositories:
 - donor
 - donor_base
 - recipient

The idea is that donor_base and recipient have the same pristine, but
potentially different patches.

The idea is that if we do

  cd donor_base
  darcs transplant donor recipient

We reconstruct the sequence of patches that go from donor-base to donor in the
recipient repo.

Just some rough thoughts.  Would something like this be useful?

Maybe a simpler UI

  cd donor;
  darcs transplant --last=3 recipient

Again the idea being that donor minus the last 3 patches has the same pristine
as the recipient.

  darcs transplant --from-tag=foo recipient

Also,

  darcs transplant recipient

could just succeed trivially, warning the user that he didn't select any patches.

http://bugs.darcs.net/issue1161 may be a good use for this kind of command (as
an example of using darcs transplant to recover from repository corruption)

Here's a transcript from a real-world use case where this command
would have been useful.  Note that after spending OVER TWO HOURS
manually transplanting only 13 patches, I'm still not done!

00:21 <twb> I want darcs transplant!
00:22 <twb> I foolishly recorded a one-line change to documentation as part of a makefile patch (because they were related).
00:22 <twb> Now there are 13 other patches that depend on that, because of that one line!
00:23 <twb> I want to obliterate the makefile patch, because it causes lots of conflicts with the main branch
00:23 [kowey sympathises]
00:24 <twb> Now what I'm going to do is obliterate all 13, then manually record them again using darcs diff | patch
[...]
01:55 <twb> AAAAAAARGH
01:55 <twb> ARGH ARGH ARGH
01:55 <twb> So I had --diff-opts -wpurd in my .darcs/defaults
01:56 <twb> So all this manual transplanting I've just done is demonstrably lossy and fucked up
01:56 <twb> I have to start again

Several (all?) of the examples people have given in this thread of why
they need rebase involve rewriting history in ways that darcs doesn't
(or at least darcs 1 didn't) allow.  But don't the new darcs 2
semantics, in which identical changes are considered not to conflict,
actually let you do what you need?

Consider the following sequence.

mkdir repo1
cd repo1
darcs init
echo fileA version 1 > fileA
echo fileB version 1 > fileB
darcs add fileA fileB
darcs record --all -m "Add fileA and fileB"
echo fileA version 2 > fileA
darcs record --all -m "Modify fileA"
cd ..
darcs get repo1 repo2
cd repo2
darcs obliterate -p "Modify fileA" --all
darcs unrecord -p "Add fileA and fileB" --all
darcs record --all fileA -m "Add just fileA"
darcs revert --all
darcs pull --all ../repo1
darcs obliterate -p "Add fileA and fileB" --all

The patch called "Modify fileA" originally depends on "Add fileA and
fileB", but in the end repo2 contains the former but not the latter.
The patch "Add just fileA" has taken the place of "Add fileA and
fileB" in the dependencies of "Modify fileA".

However, when I do the same thing with the patches in a different
order, darcs chokes, so maybe this isn't entirely worked out yet.
See http://bugs.darcs.net/issue1327

The new darcs 2 semantics can help, but I think what most folks have in mind
here involves some deliberately "destructive" operations (i.e. rewriting
history, as you say), for example if you have

Patch 1
-------
- add these awfully huge files
- add these nice small files

Patch 2
-------
- delete just the huge files

Patch 3
-------
- modify the small files

It would be nice to preserve half of Patch 1 and Patch 3, while completely
annihilating the other half (and Patch 2).  Same end result, just less cruft in
the history.  This would only be a sort of emergency repair option (at least,
goes the intention), or be something one could use in the case of long-term
branches trying to co-operate more gently with the mainline...

That's what I'm saying, you can do exactly that now.  To the repo you described
above, add the following:

Patch 1a
-------
- add these nice small files

which does just the part of Patch 1 that you want to keep. In darcs 1 it would
have conflicted with Patch 1, but in darcs 2 the two of them can coexist.  Now
you can obliterate Patch 1 and Patch 2, leaving Patch 1a and Patch 3 in place.
Patch 3 originally depended on Patch 1, but once Patch 1a is in the repository
Patch 3 has a disjunctive dependency on either Patch 1 or Patch 1a, which means
you can obliterate Patch 1.

On Sat, Jan 31, 2009 at 21:24:26 -0000, Aaron Kaplan wrote:
> That's what I'm saying, you can do exactly that now.  To the repo you described
> above, add the following:
> 
> Patch 1a
> -------
> - add these nice small files

It sounds like you're right.  We would need somebody who understands
darcs more deeply (say, Ian) to be sure, though.

It looks like doing things this way would have to wait till darcs 3,
however, because of our concerns about how well the darcs 2 semantics
actually works (better than darcs 1, but does it really handle the new
stuff like we want? see http://bugs.darcs.net/issue1014 and the
corresponding test case in the bugs/ directory).  See also Ian's work on
camp and named primitive patches (an idea which has been endorsed in
principle to be darcs 3).  But yes, users could be helped by some sort
of user-interface level change that simplifies this kind of procedure,
which is what transplant could be.  Something like a group/ungroup
command could be useful, for example.

That said, I /still/ suspect that some sort of nuclear-ish last resort
editing command could be useful, for example, for cases where an old
version of darcs got things wrong, e.g. with pristine corruption before
the hashed repo days).  Examples (or counter-points!) welcome.

Hmm...

A bzr weenie brought this post to my attention.
It seems relevant to this discussion, particularly with respect
to GHC's desire for (AIUI) long-lived feature branches.
http://fourkitchens.com/blog/2009/04/20/alternatives-rebasing-bazaar

I think this feature is crucial to sort out soon particularly given the merging
difficulties with David's darcs and the ongoing issues it causes the GHC developers.

I discussed it a bit with Simon Marlow and Ian today and I think I have a
reasonable design (which I will write up as soon as I have time, perhaps on the
wiki for reasons of space and disconnected editability).

I have a feeling that it will be possible to implement at least some aspects of
the feature as a separate application using the darcs library, without depending
on too much stuff that's likely to change fast. If this is indeed feasible, is
it desirable?

Aaron: to answer your comments, I think your suggestion probably works ok, but
the merging of duplicate patches is a misfeature in darcs-2 semantics that
causes more trouble than gain, so I'm very reluctant to base anything on it.
It's also not available for darcs-1 repos and I believe that camp won't have it
either.

A status update on this:

The design is roughed out and much of the code is written. But there's a 
lot left to do - some basic implementation and a lot of polishing. I 
think trying to get this done in time for 2.5 may be difficult. I 
haven't given up completely on this, but will not be pushing hard to 
make it.

As soon as something basically usable is available, I will publish it 
separately for interested early adopters to try out and give feedback 
on. This should be weeks rather than months.

http://wiki.darcs.net/Ideas/RebaseDesign has a rough summary of the 
current status etc.

Does this ticket need to remain open at this point, since "rebase" has 
been merged as a feature now?

markstos, I think not, moreover there are other tickets to discuss 
specific issues of the current implementation. I close the ticket.

And which release has it been merged into?

(Well, I see the "2.8.0" milestone above, but milestones feel more like 
promises, rather than facts. That's why I'm asking.)

Apologies - it's merged into 2.10.0 (so will definitely be released in 
that in some form).