On Tue, Sep 24, 2013 at 09:15:24AM +0100, Daniel Silverstone wrote:
On Mon, Sep 23, 2013 at 18:00:51 +0100, Richard Maw wrote:
> The petrify code between old-petrify and this petrify does not work.
I'm confused as to what you mean by this.
We've had 3 versions of petrify.
- old-petrify is from before refactoring, it works but was very slow
- the currently merged petrify is broken, I considered reverting when
I found the issue, but after discussion decided to fix it asap instead
- the petrify in this patch series fixes the problems with the current
> This will not work with system branches created before the
> the source of system branches" patch, since I need more information than
> is stored.
> If this is an issue, I can prepare a patch that will generate an exception
> saying how to fix it, or assume it came from master.
I'd like to see something to help users to understand how to fix things.
Frankly assuming any given source branch is a little daft.
Agreed, the suggestion was because it's rare for us to create branches
that weren't from master.
Is there some way you could add a teeny helper command short-term to
allow users to record where they branched from without re-branching?
There's enough context available when the error occurs to provide a git
config command line to set it.
I'm not sure I want a new subcommand for fixing this since people might
use it when they shouldn't, whereas it's more clear you shouldn't be
messing about with the contents of .morph-system-branch/config
Not least if person A branches and person B checks out the branch,
only person A can petrify given your description above, no?
I don't understand what is meant by this, the state is stored in the workspace.
If A branched before this patch but upgraded their version of morph,
they would not be able to petrify.
If A pushed that branch then B checked it out, B would be able to
Similarly if A checked the branch out again they would be able to