# stgit restrictions on patch names

3 messages from 2007-10-25 to 2007-10-29. Participants: Yann Dirson, Karl Hasselström, Catalin Marinas.
Thread: https://gitlist.dev/t/10464

## Yann Dirson, 2007-10-25 19:48

Subject: stgit restrictions on patch names
Message-ID: <20071025194808.GV26436@nan92-1-81-57-214-146.fbx.proxad.net>
URL: https://gitlist.dev/e/20071025194808.GV26436%40nan92-1-81-57-214-146.fbx.proxad.net

```
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 "+" ?

```

## Karl Hasselström, 2007-10-26 07:29

Subject: Re: stgit restrictions on patch names
Message-ID: <20071026072924.GA11286@diana.vm.bytemark.co.uk>
URL: https://gitlist.dev/e/20071026072924.GA11286%40diana.vm.bytemark.co.uk
In-Reply-To: <20071025194808.GV26436@nan92-1-81-57-214-146.fbx.proxad.net>

```
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

```

## Catalin Marinas, 2007-10-29 16:14

Subject: Re: stgit restrictions on patch names
Message-ID: <b0943d9e0710290914p4163ffabt5767fdb2ab8d91d4@mail.gmail.com>
URL: https://gitlist.dev/e/b0943d9e0710290914p4163ffabt5767fdb2ab8d91d4%40mail.gmail.com
In-Reply-To: <20071025194808.GV26436@nan92-1-81-57-214-146.fbx.proxad.net>

```
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

```