On Fri, May 29, 2015 at 1:56 AM, Andy Bradford amb-fos...@bradfords.org wrote:
fossil edit UUID ?OPTIONS?
I'll second that!
But if I could say, the option newbranch does not look good at me,
since it a little too long. Coming from git I'm used to a short
command line, while fossil tend to be
From the download page for v1.33, Improved ability to customize the
timelime graph https://www.fossil-scm.org/customgraph.md is a broken
link.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
On 5/29/15, Eric Rubin-Smith eas@gmail.com wrote:
From the download page for v1.33, Improved ability to customize the
timelime graph https://www.fossil-scm.org/customgraph.md is a broken
link.
Tnx. Should be working better now.
--
D. Richard Hipp
d...@sqlite.org
On Fri, May 29, 2015 at 10:45 AM, Andy Bradford amb-fos...@bradfords.org
wrote:
Thus said Luca Ferrari on Fri, 29 May 2015 13:59:17 +0200:
But if I could say, the option newbranch does not look good at me,
since it a little too long.
Fossil can have both long and short names for a
Hi Andy,
On 29 May 2015 at 07:45, Andy Bradford amb-fos...@bradfords.org wrote:
Anyone else have an opinion on whether or not ``fossil edit'' should
exist?
I think it's a good idea as it will support additional edit commands
that we don't yet know about.
--
---
inum: 883510009027723
This is an exceedingly confusing behavior from fossil but the fix is easy.
Just do fossil up trunk.
On Thu, May 28, 2015 at 11:36 AM, Richard Hipp d...@sqlite.org wrote:
On 5/28/15, jungle Boogie jungleboog...@gmail.com wrote:
Hello All,
I follow and update from trunk pretty
On 29 May 2015 at 08:38, Richard Hipp d...@sqlite.org wrote:
On 5/29/15, Matt Welland mattrwell...@gmail.com wrote:
This is an exceedingly confusing behavior from fossil but the fix is easy.
Just do fossil up trunk.
Indeed - Fossil is doing exactly the right thing here. If you just
fossil
Thus said Luca Ferrari on Fri, 29 May 2015 13:59:17 +0200:
But if I could say, the option newbranch does not look good at me,
since it a little too long.
Fossil can have both long and short names for a given option, but
perhaps --newbranch is too long. What about just --branch?
On Fri, May 29, 2015 at 7:59 AM, Luca Ferrari fluca1...@infinito.it wrote:
On Fri, May 29, 2015 at 1:56 AM, Andy Bradford amb-fos...@bradfords.org
wrote:
fossil edit UUID ?OPTIONS?
I'll second that!
But if I could say, the option newbranch does not look good at me,
since it a little too
On 5/29/15, Matt Welland mattrwell...@gmail.com wrote:
This is an exceedingly confusing behavior from fossil but the fix is easy.
Just do fossil up trunk.
Indeed - Fossil is doing exactly the right thing here. If you just
fossil update it advances you to the tip of whatever branch your are
On Fri, 29 May 2015 17:38:39 +0200, Richard Hipp d...@sqlite.org wrote:
On 5/29/15, Matt Welland mattrwell...@gmail.com wrote:
This is an exceedingly confusing behavior from fossil but the fix is
easy.
Just do fossil up trunk.
Indeed - Fossil is doing exactly the right thing here. If you
Thus said to...@acm.org on Fri, 29 May 2015 20:57:16 +0300:
Is my repo corrupt or what's wrong with the new (or the old) version?
Did you remember to make clean before building and optionally rerun
./configure?
Thanks,
Andy
--
TAI64 timestamp: 40005568acbb
I updated to this recent version of fossil:
This is fossil version 1.33 [282ae5e4de] 2015-05-28 17:05:13 UTC
Compiled on May 28 2015 21:56:18 using msc-18.00 (32-bit)
SQLite 3.8.10.2 2015-05-20 18:17:19 2ef4f3a5b1
Schema version 2015-01-24
zlib 1.2.8, loaded 1.2.8
SSL (OpenSSL 1.0.2a 19 Mar 2015)
Thus said to...@acm.org on Fri, 29 May 2015 20:57:16 +0300:
(1) 2015-05-29 17:48:57 [eba9fa6147] (current)
(2) 2014-11-05 13:36:22 [91ef16c613]
What artifacts are these? Fossil doesn't have them:
https://www.fossil-scm.org/index.html/info/eba9fa6147
Thus said to...@acm.org on Sat, 30 May 2015 01:29:10 +0300:
And, using --force does nothing, of course.
Actually, it does. Did you try to run ``fossil ci'' after running
``fossil merge --force'' to actually commit your changes?
There will be no files changed as part of the merge,
Thus said to...@acm.org on Sat, 30 May 2015 01:29:10 +0300:
As to what happened you probably guessed right. I must have used the
--branch option from within the 'mistake' branch. I was (until just
now) under the impression that the --branch option either starts a new
branch (if the name
Matt Welland writes:
We emphatically do NOT want Fossil second-guessing what branch you
want to be on when you do fossil update without an argument.
[...]
The right thing from a user perspective is to either WARN the user
that the branch was swizzled out from under them or WARN them and
On Fri, May 29, 2015 at 6:29 PM, to...@acm.org wrote:
As to what happened you probably guessed right. I must have used the
--branch option from within the 'mistake' branch. I was (until just now)
under the impression that the --branch option either starts a new branch
(if the name given is
On 2015-05-29 19:19, Ron W wrote:
I suspect, in most case, multiple independent branches with the same
name are not a problem. But trunk is a special case that may warrant a
warning.
I don't think I'd take that suspicion to the bank. Personally, I think
it should warn on duplication of an
On 5/26/2015 3:02 PM, Richard Hipp wrote:
On 5/26/15, Will Parsons varro@nodomain.invalid wrote:
On Tuesday, 26 May 2015 3:20 PM -0400, Richard Hipp wrote:
I think the best solution is to actually create a /dev/null and
/dev/urandom inside of your chroot jail. (That's what the
(BTW, this is a private repo).
So, if this is a new feature, it means the problem was there all along and I
simply now found out about it! Great!
What I see at that time is the following (I hope the image won’t disappear – if
it does, get it here:
We emphatically do NOT want Fossil second-guessing what branch you
want to be on when you do fossil update without an argument.
Whatever option you decide - either way you are second guessing the users
intent.
1. Current behavior is really, really confusing.
2. You *were* on trunk but magically
On 29 May 2015 at 10:57, to...@acm.org wrote:
Is my repo corrupt or what’s wrong with the new (or the old) version?
This is the new advisory system in 1.33:
https://www.fossil-scm.org/index.html/doc/trunk/www/changes.wiki
Improved fork detection on fossil update, fossil status and related
On 5/29/15, to...@acm.org to...@acm.org wrote:
I updated to this recent version of fossil:
This is fossil version 1.33 [282ae5e4de] 2015-05-28 17:05:13 UTC
Compiled on May 28 2015 21:56:18 using msc-18.00 (32-bit)
SQLite 3.8.10.2 2015-05-20 18:17:19 2ef4f3a5b1
Schema version 2015-01-24
zlib
Thus said to...@acm.org on Fri, 29 May 2015 22:18:00 +0300:
Check-in d137 was originally trunk but moved to a branch ``mistake.''
(I guess shunning would have been a better solution at the time, but
too late now, right?)
Actually, shunning was probably never a better solution for this kind
25 matches
Mail list logo
