stgit restrictions on patch names

stgit restrictions on patch names

[Yann Dirson]

Looks like stgit is now more picky on patch names than in used to be:

$ stg branch --clone v2.0.6-debian
Checking for changes in the working directory ... done
Cloning current branch to "v2.0.6-debian" ...
  No log for 01_springelectrical
stg branch: Invalid patch name: "10_g++4.0_build_failures"
$


=> the result of the cloning operation is a partial clone.  Do we want to:

- implement a mechanism for checking beforehand that the operation
will not fail ?  Seems awkward to duplicate checks already found
elsewhere.

- wait for proper transactions so we can rollback on error ?

- on clone error, delete the newly-created stack ?  I'd vote for this
one, until the previous one gets done.


=> is there any particular reason why we would refuse "+" ?

Re: stgit restrictions on patch names

[Karl Hasselström]

On 2007-10-25 21:48:08 +0200, Yann Dirson wrote:

> Do we want to:
>
> - implement a mechanism for checking beforehand that the operation
> will not fail? Seems awkward to duplicate checks already found
> elsewhere.

Duplication is bad. Calling the same verification function more times
than necessary is still bad, but maybe not so bad that it wouldn't be
OK.

> - wait for proper transactions so we can rollback on error ?

Yes, this is what we should aim for. I'm working on code that'll
eventually give us this if it pans out.

> - on clone error, delete the newly-created stack ? I'd vote for this
> one, until the previous one gets done.

Seems reasonable.

> => is there any particular reason why we would refuse "+" ?

Not that I can think of at the moment, except maybe future-proofing.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

Re: stgit restrictions on patch names

[Catalin Marinas]

On 25/10/2007, Yann Dirson <ydirson@altern.org> wrote:
> Looks like stgit is now more picky on patch names than in used to be:

It's not that we explicitly disallows "+" but I think I tried to avoid
some wrong patch names but was too lazy to create a better regexp.

As a quick fix, we could re-generate a patch name if it is invalid.

> => the result of the cloning operation is a partial clone.  Do we want to:
>
> - implement a mechanism for checking beforehand that the operation
> will not fail ?  Seems awkward to duplicate checks already found
> elsewhere.
>
> - wait for proper transactions so we can rollback on error ?
>
> - on clone error, delete the newly-created stack ?  I'd vote for this
> one, until the previous one gets done.

I think the last one is the simplest to implement, while the second is
nicer, I've never found the time to investigate it properly.

-- 
Catalin