I am a fan of both of these changes. However, does everybody think they
have had enough testing to be included in a release that is "imminent"?
I just reviewed the changes again and I'm starting to think they are low
risk enough to include in 1.33. Does anybody disagree?
--
Joe Mistachkin
___
On 5/15/2015 12:02 AM, Andy Goth wrote:
> On 5/8/2015 1:13 PM, Warren Young wrote:
>> On May 7, 2015, at 6:21 PM, Andy Goth wrote:
>>> My question is whether this extra level of reporting should be standard
>>> [fossil changes] behavior or only accessible if an extra option is
>>> supplied. My vo
On 5/8/2015 1:13 PM, Warren Young wrote:
> On May 7, 2015, at 6:21 PM, Andy Goth wrote:
>> My question is whether this extra level of reporting should be standard
>> [fossil changes] behavior or only accessible if an extra option is
>> supplied. My vote is to make it always report execute bit and
On Thu, May 14, 2015 at 4:37 PM, paul wrote:
>
> But a developer could just disable the hook code in the local repository?
> There wouldn't be anything to stop that. Or am I misunderstanding something?
>
If a dev wants to do that, he could. But a dev who is merely distracted, is
unlikely to do th
On 14/05/15 20:04, Ron W wrote:
I don't think it's likely a distracted dev will override or subvert
the rules imposed by the hook mechanism. A dev determined to get
around the rules is a completely different issue.
But a developer could just disable the hook code in the local
repository? Th
On Thu, May 14, 2015 at 1:51 PM, paul wrote:
> It wouldn't offer much control over a distracted programmer, because
> your local repo is always going to be under the full control of the user on
> the local machine - no hacking required.
>
As I previously pointed out, with any DVCS - not just Fo
Tnx for the message. Fixed now on trunk.
https://www.fossil-scm.org/fossil/info/648dc3e7046d657a
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinf
Eric
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
On 13/05/15 16:45, Ramon Ribó wrote:
Hello,
A reasonable solution could be a pre-commit hook, where the script in
TH1 or TCL had access to the branch name of the commit and other
details. As a result, the hook could accept the commit, raise a
warning, ask for confirmation or deny the commit.
On Wed, May 13, 2015 at 11:38 PM, Stéphane Aulery
wrote:
> Le mercredi 13 mai 2015 à 03:42:30, Warren Young a écrit :
> > On May 13, 2015, at 3:14 PM, Stéphane Aulery wrote:
> > >
> > > I could not find how to report this bug to
> > > the tracker. This is subject to the Agreement as well as the
On 5/13/15, Tony Papadimitriou wrote:
> Hello,
>
> Is there a way to see a ‘diff’ between two stashed ids, rather than stash to
> disk?
>
How about
fossil stash goto ID1
fossil stash diff ID2
--
D. Richard Hipp
d...@sqlite.org
___
foss
Hi Martin,
This was attempted but did not resolve the problem. Thanks for the
contribution; the problem was bogus whitespace.
May be you can set 'Gary_Gabriel_Dev' as the default user for this repo.
$ fossil user default Gary_Gabriel_Dev
- Gary Gabriel
Hi Warren,
Thanks for the excellent explanations and helping me understand the
problem. The syntax error was a good catch.
This was right on. There was "bogus whitespace in the user name" that
the query with 'fossil sqlite' rendered. Other comments follow.
The fact that the “default" comma
13 matches
Mail list logo
