On May 14, 2015, at 11:02 PM, Andy Goth andrew.m.g...@gmail.com wrote:
On May 7, 2015, at 6:21 PM, Andy Goth andrew.m.g...@gmail.com wrote:
extra level of reporting
I made it standard in [fossil changes] and [fossil status]. See commit
[03679b58]. Please give it a whirl and let me know
On 5/15/2015 12:02 AM, Andy Goth wrote:
I made it standard in [fossil changes] and [fossil status]. See commit
[03679b58]. Please give it a whirl and let me know if it satisfies.
As you may have noticed, I decided to move this change to a branch
called andygoth-metadata-changes. The
On May 15, 2015, at 9:50 AM, Andy Goth andrew.m.g...@gmail.com wrote:
drh's preference seems to be to make an additional check-in highlighting
the release. I imagine the reason he does this is so that the comment
can simply say something like Version 3.8.10.1, rather than describing
the
On May 14, 2015, at 11:02 PM, Andy Goth andrew.m.g...@gmail.com wrote:
Please give it a whirl and let me know if it satisfies.
I just tried 1.33 [209da9bced] on a Linux box, and neither “chmod +x
existing-text-file” nor “chmod -x bin/existing-script results in a noted
change in “fossil
On May 15, 2015, at 9:00 AM, Richard Hipp d...@sqlite.org wrote:
On 5/15/15, Warren Young w...@etr-usa.com wrote:
Discovered a side effect. This reduces the need for the -allow-empty
option to [fossil commit] since it is now aware of execute and symlink
changes.
Nice! I never liked that
On 5/15/2015 10:43 AM, Warren Young wrote:
On May 15, 2015, at 9:00 AM, Richard Hipp d...@sqlite.org wrote:
The whole purpose of --allow-empty is to force Fossil to do a
check-in that deliberately has no changes from the previous check-in.
This is done, for example, to tag a release.
I can
On 5/15/2015 10:46 AM, Warren Young wrote:
On May 14, 2015, at 11:02 PM, Andy Goth andrew.m.g...@gmail.com wrote:
Please give it a whirl and let me know if it satisfies.
I just tried 1.33 [209da9bced] on a Linux box, and neither “chmod +x
existing-text-file” nor “chmod -x
On 5/15/15, Warren Young w...@etr-usa.com wrote:
Discovered a side effect. This reduces the need for the -allow-empty
option to [fossil commit] since it is now aware of execute and symlink
changes.
Nice! I never liked that flag anyway. Maybe it can be de-documented, then
maybe later
On 5/15/2015 12:52 PM, Andy Goth wrote:
This problem appears to be fixed. Please see andygoth-metadata-changes
if works for you. Repeating the test case from the previous email
(repeated below) gives a good result with no changes shown after the
final commit.
$ f version
This is fossil
On May 15, 2015, at 11:52 AM, Andy Goth andrew.m.g...@gmail.com wrote:
This problem appears to be fixed. Please see andygoth-metadata-changes
Thank you, this now does exactly what I expect on OS X, Linux, and Cygwin.
___
fossil-users mailing list
On 5/15/2015 11:01 AM, Andy Goth wrote:
As you may have noticed, I decided to move this change to a branch
called andygoth-metadata-changes. The (updated) comment:
BUG: [fossil commit] does not reset the chnged flag for files whose
contents have not changed, i.e. files whose only change is
On 5/15/2015 12:52 PM, Andy Goth wrote:
$ mkdir .settings
Correction #2. I meant .fossil-settings.
Argh! Sorry for spamming the list.
--
Andy Goth | andrew.m.goth/at/gmail/dot/com
signature.asc
Description: OpenPGP digital signature
___
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
On May 7, 2015, at 6:21 PM, Andy Goth andrew.m.g...@gmail.com wrote:
many times I've unwittingly checked in a
bunch of execute or symlink brokenness
This frequently happens to me on Windows under Cygwin due to the historical use
of the archive attribute to emulate the execute bit. An
I propose extending [fossil changes] to report when a file's execute bit
has changed or it has become a symlink or ceased to be a symlink.
For various annoying reasons, many times I've unwittingly checked in a
bunch of execute or symlink brokenness, sometimes not discovering it
until much later.
Any improvement to the handling of symlinks gets my vote!
../Dave
On 7 May 2015 at 23:25, Abilio Marques abili...@gmail.com wrote:
+1. Been there, two times just in the last week (I need to sleep better).
On Thu, May 7, 2015 at 7:51 PM, Andy Goth andrew.m.g...@gmail.com wrote:
I propose
+1. Been there, two times just in the last week (I need to sleep better).
On Thu, May 7, 2015 at 7:51 PM, Andy Goth andrew.m.g...@gmail.com wrote:
I propose extending [fossil changes] to report when a file's execute bit
has changed or it has become a symlink or ceased to be a symlink.
For
18 matches
Mail list logo
