On Wed, May 13, 2015 at 11:38 PM, Stéphane Aulery saul...@legtux.org
wrote:
Le mercredi 13 mai 2015 à 03:42:30, Warren Young a écrit :
On May 13, 2015, at 3:14 PM, Stéphane Aulery saul...@legtux.org wrote:
I could not find how to report this bug to
the tracker. This is subject to the
On 5/13/15, Tony Papadimitriou to...@acm.org 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
Eric
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
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
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
On Thu, May 14, 2015 at 1:51 PM, paul pault.eg...@gmail.com 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
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?
On Thu, May 14, 2015 at 4:37 PM, paul pault.eg...@gmail.com 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
On 5/8/2015 1:13 PM, Warren Young wrote:
On May 7, 2015, at 6:21 PM, Andy Goth andrew.m.g...@gmail.com 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
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 andrew.m.g...@gmail.com wrote:
My question is whether this extra level of reporting should be standard
[fossil changes] behavior or only accessible if an extra option is
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
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 command
13 matches
Mail list logo
