On Aug 4, 2015, at 1:18 PM, Warren Young wrote:
>
> On Aug 4, 2015, at 8:51 AM, Ron W wrote:
>
>> Also, if "pop --partial" were also implemented
>
> I think “pop --partial” only makes sense if it actually modifies the stash to
> contain only the un-popped partial changes, which seems a bit…ex
On Aug 4, 2015, at 1:53 PM, Joe Mistachkin wrote:
>
> Warren Young wrote:
>>
>> Fossil currently forces a two-step mv
>
> No, it doesn't. Fossil now has the --hard option for mv/rm.
Ah, I completely missed the announcement of that feature.
However, this feature is not available by default, a
Warren Young wrote:
>
> Fossil currently forces a two-step mv, which is different from *every
> other popular F/OSS VCS* except for CVS, and that's only because CVS
> doesn't have mv at all.
>
No, it doesn't. Fossil now has the --hard option for mv/rm. Also, it
can be compiled in such a way tha
On Aug 4, 2015, at 8:51 AM, Ron W wrote:
>
> An implicit pop would be contrary to the normal behavior of "apply”.
That’s fine. It’s very much a nonessential part of the design. Just trying to
save someone a step there.
> Also, if "pop --partial" were also implemented, not popping would be co
On Aug 3, 2015, at 4:35 PM, Andy Goth wrote:
>
> On 8/3/2015 3:37 PM, Warren Young wrote:
>> On Aug 3, 2015, at 12:49 PM, Andy Goth wrote:
>>> On 8/3/2015 2:01 AM, Michai Ramakers wrote:
>>>
>>> Any plans to bring them in sync?
>>
>> We had a long thread about it months ago:
>
> Pretty sure h
On Aug 3, 2015, at 4:20 PM, Andy Goth wrote:
>
> On 8/3/2015 3:24 PM, Warren Young wrote:
>> I thought I saw reference on this list to a way to lop off the
>> most-recent checkin
>
> Using the web interface, you can edit the existing check-in to be in a
> branch (I usually use the name "mistake"
On Tue, 4 Aug 2015, Ron W wrote:
> On Tue, Aug 4, 2015 at 11:37 AM, Stephan Beal wrote:
> On Tue, Aug 4, 2015 at 5:23 PM, Ron W
> wrote:
> I think this would be a useful feature.
>
>
> To me this all sounds like fossil enforcing project-specific policy,
> which is somethi
On Tue, Aug 4, 2015 at 11:37 AM, Stephan Beal wrote:
> On Tue, Aug 4, 2015 at 5:23 PM, Ron W wrote:
>
>> I think this would be a useful feature.
>>
>
> To me this all sounds like fossil enforcing project-specific policy, which
> is something it most certainly should not be doing.
>
I was commen
On Tue, Aug 4, 2015 at 11:37 AM, Stephan Beal wrote:
> On Tue, Aug 4, 2015 at 5:23 PM, Ron W wrote:
>
>> I think this would be a useful feature.
>>
>
> To me this all sounds like fossil enforcing project-specific policy, which
> is something it most certainly should not be doing.
>
> Case in poi
On Tue, Aug 4, 2015 at 5:23 PM, Ron W wrote:
> I think this would be a useful feature.
>
To me this all sounds like fossil enforcing project-specific policy, which
is something it most certainly should not be doing.
Case in point:
[odroid@host:~/fossil/cwal/s2]$ ls -d *
1mod_porex.c s
On Mon, Aug 3, 2015 at 6:33 PM, Andy Goth wrote:
>
> Maybe split this functionality from the commit command and make a new
> warning or audit or check command which will print all the things that
> may prevent a commit from going forward, but also toss in extra files if
> the check-extras setting
On Mon, Aug 3, 2015 at 3:49 PM, Warren Young wrote:
>
> Okay, how about this design, then:
>
> $ fossil stash save -m “several unrelated changes”
> $ fossil stash apply --partial
>
> If you say “apply --partial” and Fossil sees that all stashed chunks are
> already applied, it could implic
On Tue, 4 Aug 2015, Stephan Beal wrote:
> On Tue, Aug 4, 2015 at 1:47 PM, Sergei Gavrikov
> wrote:
> I know one, that's 'The Infinitely Profitable Program'
>
> http://peetm.com/blog/?p=55 :-)
>
>
> To summarize:
>
> "GO.COM contained no program bytes at all – it was entirely empty.
On Tue, Aug 4, 2015 at 1:47 PM, Sergei Gavrikov
wrote:
> I know one, that's 'The Infinitely Profitable Program'
>
> http://peetm.com/blog/?p=55 :-)
To summarize:
"GO.COM contained no program bytes at all – it was entirely empty. However,
because GO.COM was empty, but still a valid program fi
On Tue, 4 Aug 2015, Stephan Beal wrote:
> On Tue, Aug 4, 2015 at 1:02 PM, David Mason wrote:
> Just be careful not to shun 0 length files or you won't be
> able to commit a 0-length file until you've cleared the shun
> table (because all 0-length files have the same SHA-1 id.
On Tue, Aug 4, 2015 at 1:02 PM, David Mason wrote:
> But it's a reasonable way to remove binaries that you don't want.
>
Indeed - my point was only that shunning as a feature is _primarily_
intended as a way to remove sensitive or malicious stuff.
> Just be careful not to shun 0 length file
On 4 August 2015 at 06:09, Stephan Beal wrote:
> On Tue, Aug 4, 2015 at 12:04 PM, Luca Ferrari
> wrote:
>
>> On Tue, Aug 4, 2015 at 11:31 AM, Stephan Beal
>> wrote:
>> > http://www.fossil-scm.org/index.html/help?cmd=/shun
>>
> In that case you would have to shun all of the files individually. F
On Tue, Aug 4, 2015 at 12:04 PM, Luca Ferrari wrote:
> On Tue, Aug 4, 2015 at 11:31 AM, Stephan Beal
> wrote:
> > http://www.fossil-scm.org/index.html/help?cmd=/shun
> >
> > shunning is the only way to remove something and should be considered a
> > "last resort" option.
> >
>
> Thanks, but not
On Tue, Aug 4, 2015 at 11:31 AM, Stephan Beal wrote:
> http://www.fossil-scm.org/index.html/help?cmd=/shun
>
> shunning is the only way to remove something and should be considered a
> "last resort" option.
>
Thanks, but not quite what I was searching for: I need to remove a
full tree of files, s
On Tue, Aug 4, 2015 at 11:22 AM, Luca Ferrari wrote:
> Hi,
> this may sound stupid, but once I've mistakenly committed binary
> files, is there a way to remove them from the repository at all?
> My attempt is (i) to not version such files and (ii) reduce repository
> size.
>
see:
http://www.fos
Hi,
this may sound stupid, but once I've mistakenly committed binary
files, is there a way to remove them from the repository at all?
My attempt is (i) to not version such files and (ii) reduce repository size.
Thanks,
Luca
___
fossil-users mailing list
21 matches
Mail list logo
