On 8/13/16, Kain Abel wrote:
> The next try: another version.
>
> (Prevents the growth from stash id after many push and pop operations.)
But you still have not made your case for why growth of the stash id
is a bad thing.
>
> Just for the sake of completeness,
> Kain
>
--
D. Richard Hipp
d..
The next try: another version.
(Prevents the growth from stash id after many push and pop operations.)
Just for the sake of completeness,
Kain
stash-next_fix_fix.patch
Description: Binary data
___
fossil-users mailing list
fossil-users@lists.fossil-sc
Hi,
2016-08-13 16:38 GMT+02:00 Richard Hipp :
>
> And thus each new stash has a unique id. Is that a problem?
not really, but the id is growing up.
Uh, my patch doesn't work, when the last stash will be dropped.
if( stashid==0 ) fossil_fatal("empty stash");
in line 401 will break the efforts. :
On 8/13/16, Kain Abel wrote:
>
> after
> $ fossil stash pop
> or
> $ fossil stash rm
> is the pointer for the next stash id (stash-next in table vvar) untouched.
And thus each new stash has a unique id. Is that a problem?
--
D. Richard Hipp
d...@sqlite.org
__
Dear developers,
after
$ fossil stash pop
or
$ fossil stash rm
is the pointer for the next stash id (stash-next in table vvar) untouched.
Here a tiny patch hopefully without side effects.
With regards,
Kain
stash-next_fix.patch
Description: Binary data
_
5 matches
Mail list logo