selectively applying changesets

[Matt Mackall]

On Sun, Sep 25, 2005 at 02:08:55PM -0700, Eric M. Hopper wrote:
> On Sun, 2005-09-25 at 22:50 +0200, Stefan van der Walt wrote:
> > Say two users, A and B, are working on a project.  B clones the latest
> > stable release and adds two features (as changesets 1 through 10 and
> > 20 through 30, separately) into his public repository.  User A then
> > decides to merge back only the first feature, changesets 1 through 10,
> > into his repository.
> > 
> > In pseudo-hg, A wants to do something like:
> > 
> > $ hg pull -r 1:10 B
> > $ hg update -m
> > 
> > Is an export/import the appropriate way to do this?
> 
> Currently, export/import is the only way to do this, but it isn't a very
> good way.  Mostly because the changesets will not be properly identified
> with the same unique hashes on the import side as they are on the export
> side.
> 
> This means if you ever do an actual 'pull' from a remote repository, you
> will get all the same changes again, but they will be considered to be
> different changesets that happen on a branch.
> 
> There are ways to sort of simulate the behavior you want by pulling
> _all_ the changes, then updating to a particular changset and branching
> off from there.  But it isn't really quite the same.  Also, if a lot of
> people do this eventually there'll end up being this vast sea of
> orphaned changsets that keep moving from repository to repository but
> are basically dead as far as new development based on them is concerned.
> 
> I've been thinking of good ways to deal with this problem, as my own
> development style would tend to create a lot of these orphaned branches
> that should probably never be seen outside my repositories.

To handle this problem we need:

- a way to remember which changesets we didn't want, and why, and
  when, and by who
- a way to deal with the inter-changeset dependencies
- a way to record that information in a form that works naturally with
  history, merge, annotate, etc.
- a way to propagate this information to other users

Which is I why the solution I've personally been using is[1]:

  hg export <unwanted changeset> | patch -p1 -R
  hg ci -m <explanation>

- it stores the reversal along with a description and all the other
  appropriate information
- it handles changeset ordering problem in about the only practical
  way, namely letting the user manage it directly
- it does the right thing on future merges
- it doesn't hide or distort the history in any way
- it doesn't require inventing any new mechanisms
- and it obviously already exists and works

While some form of automation might improve on things a bit, I doubt
there's an approach which is conceptually cleaner.

[1] as a special case for when all the unwanted bits are contiguous on
the tip:

  hg revert <last good changeset>
  hg ci -m "Well THAT wasn't such a good idea"

-- 
Mathematics is the supreme nostalgia of our time.