On Dec 13, 2017, at 2:21 PM, Zakero wrote:
>
> The "fossil clean" command has the "--emptydirs" option. That might be
> useful for the "rm" command as well.
If Fossil got that option, I’d probably forget that it existed a week after the
change went in. I’d end up saying
On Wed, Dec 13, 2017 at 3:01 PM, Warren Young wrote:
> On Dec 13, 2017, at 1:03 PM, jungle Boogie
> wrote:
> >
> > On 13 December 2017 at 07:58, Warren Young wrote:
> >
> >> I’d feel differently if Fossil owned the directories,
On Dec 13, 2017, at 1:03 PM, jungle Boogie wrote:
>
> On 13 December 2017 at 07:58, Warren Young wrote:
>
>> I’d feel differently if Fossil owned the directories, but it doesn’t.
>> They’re mine; leave them alone!
>
> Yes, I agree. I think this
On 13 December 2017 at 07:58, Warren Young wrote:
> I’d feel differently if Fossil owned the directories, but it doesn’t.
> They’re mine; leave them alone!
Yes, I agree. I think this topic has been raised here in the past,
although that was about removing files. Still, If
On Dec 13, 2017, at 6:21 AM, Tino Lange wrote:
>
> The directory/directories will keep existing!
Given that Fossil doesn’t know anything about directories, other than as
containers for the files it manages, I’m not sure that isn’t the right thing.
To have Fossil remove
Hi!
When doing a
$ fossil rm --hard dir1
it will unregister from fossil and then delete all files within the
'dir1' hierarchy.
But: The directory/directories will keep existing!
I need to do a
$ rm -rf dir1
afterwards (so the whole --hard is mostly needless, since I need to do
the
On Fri, 3 Feb 2012 09:57:47 -0700 Matt Welland wrote:
If I do:
fossil rm some/file.txt
rm some/file.txt
fossil commit
People often prefer to commit when their work has reached some level
of completion or readiness and partially done commits can cause
unnecessary breakage
If I do:
fossil rm some/file.txt
rm some/file.txt
...do stuff...
fossil update
then some/file.txt is resurrected which is really really annoying when you
just got your build to work and then because files that shouldn't be there
suddenly reappear and things break.
I can see where might be some
On Fri, 3 Feb 2012 09:18:32 -0700 Matt Welland wrote:
If I do:
fossil rm some/file.txt
rm some/file.txt
fossil commit
--
Dmitry Chestnykh
http://www.codingrobots.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
On Fri, Feb 3, 2012 at 9:46 AM, Dmitry Chestnykh dmi...@codingrobots.comwrote:
On Fri, 3 Feb 2012 09:18:32 -0700 Matt Welland wrote:
If I do:
fossil rm some/file.txt
rm some/file.txt
fossil commit
People often prefer to commit when their work has reached some level of
completion or
On Fri, Feb 3, 2012 at 10:57 AM, Matt Welland estifo...@gmail.com wrote:
On Fri, Feb 3, 2012 at 9:46 AM, Dmitry Chestnykh dmi...@codingrobots.com
wrote:
On Fri, 3 Feb 2012 09:18:32 -0700 Matt Welland wrote:
If I do:
fossil rm some/file.txt
rm some/file.txt
fossil commit
People often
I think part of the original post was whether the documentation was
correct. i.e., it says uncommitted changes are retained. I would argue that
fossil rm is an uncommitted change, which should be retained. Either the
documentation is wrong or there is a bug w.r.t. fossil rm.
As a work around, you
On Fri, Feb 3, 2012 at 11:18 AM, Matt Welland estifo...@gmail.com wrote:
If I do:
fossil rm some/file.txt
rm some/file.txt
...do stuff...
fossil update
then some/file.txt is resurrected which is really really annoying when you
just got your build to work and then because files that
On Thu, Jun 24, 2010 at 10:37 AM, Kohn Bernhard bernhard.k...@ait.ac.atwrote:
Hello all,
I have experienced following behavior when removing files.
I open a repository. I would like to delete all files, so I use
fossil rm ./*
In the output of the commandline the filenames (also with
Oh no, I didn't meant to say, its important.
And yes, you are right, I use this for an obscure corner case, and doing this
with commandline is no problem.
Best regards
Bernhard
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
15 matches
Mail list logo