two branches, cherrypicking when merging.

[Uwe Brauer]

   > Assuming that the experimental changes don't immediately need the fix,
   > I tend to do it the other way around. i.e. Shelve the fix and commit
   > the experimental changes first. Then update to default before
   > unshelving and committing the fix.

Oh wait, can I unshelve *after* I switch the branch?

That is: I shelve in Uwe, then update to default then unshelve would go
into default? But if so the graph would be less clear at least for me
than the one I obtain if I merged it from the Uwe branch. (That is why I
don't like much rebase, also I agree it might be useful in large
projects and when one has to send patches).

In any case I would need the record extension to cherry pick, no? 


   > Aside from that, I generally find it extremely helpful to have a
   > separate copy of my repo for each major branch I'm working on. (And an
   > extra one for everything else.) That way when I spot a bug or other
   > issue, I can leave project1-experiment as is while dealing with the
   > other issue in project1-default. Once I've committed my changes I just
   > push the new commit(s) over to project1-experimental. If I made the
   > fix in project1-experimental and don't feel like doing a shelve, I'll
   > do a folder comparison with my diff program to easily copy the fix
   > over to project1-default for committing.

Yes I start to realize the same need, but I thought that is what
branches are for, but it seems that a clone of the repo is easier to
deal with than a overcomplex branching system.


Uwe