On Thu, Sep 13, 2012 at 04:28:00PM -0700, Russ Paielli wrote:
OK, so apparently I misunderstood in thinking that the serverless,
zero-administration claim applies to Fossil. Thanks for the clarification.
If it were true, and if it distinguished Fossil from Git, I would have used
it in my
Richard Hipp wrote:
You assume correctly.
Good to know --- just checking!
--
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│ Parents let children ride bicycles on the street. But parents do not
│ allow children to hear vulgar words. Therefore we can deduce that
│ cursing is more
On Fri, Sep 14, 2012 at 1:29 AM, Scott Robison sc...@scottrobison.uswrote:
So I've spent some time writing a small and I think portable routine to
detect if a buffer is a valid UTF-16 (either little or big endian). It
rejects buffers if they contain an odd number of bytes or contain any of
On Fri, Sep 14, 2012 at 4:31 AM, Konstantin Khomoutov
flatw...@users.sourceforge.net wrote:
On the other hand, Git is not *that* hard to learn basic concepts,
really. And it has external tools providing fancy GUIs, if needed.
My argument goes like this: Every developer has a fixed number
On Fri, Sep 14, 2012 at 07:54:27AM -0400, Richard Hipp wrote:
On Fri, Sep 14, 2012 at 4:31 AM, Konstantin Khomoutov
flatw...@users.sourceforge.net wrote:
On the other hand, Git is not *that* hard to learn basic concepts,
really. And it has external tools providing fancy GUIs, if
On Fri, Sep 14, 2012 at 07:54:27AM -0400, Richard Hipp wrote:
On Fri, Sep 14, 2012 at 4:31 AM, Konstantin Khomoutov
flatw...@users.sourceforge.net wrote:
Of all of the VCSes out there today, surely Git requires more daily
brain-cycles than any other. I'm not talking about just the
Hello,
On 14 September 2012 14:43, Lluís Batlle i Rossell vi...@viric.name wrote:
On Fri, Sep 14, 2012 at 07:54:27AM -0400, Richard Hipp wrote:
On Fri, Sep 14, 2012 at 4:31 AM, Konstantin Khomoutov
flatw...@users.sourceforge.net wrote:
Of all of the VCSes out there today, surely Git requires
On Fri, Sep 14, 2012 at 9:35 AM, Michal Suchanek hramr...@gmail.com wrote:
The thing to which promoters of immutable history are blind is that
while exact history record of development of particular feature might
be interesting and educational it is not the primary purpose if VCS.
The exact
On Fri, Sep 14, 2012 at 8:35 AM, Michal Suchanek hramr...@gmail.com wrote:
The thing to which promoters of immutable history are blind is that
while exact history record of development of particular feature might
be interesting and educational it is not the primary purpose if VCS.
That depends
On 14 September 2012 15:52, Richard Hipp d...@sqlite.org wrote:
On Fri, Sep 14, 2012 at 9:35 AM, Michal Suchanek hramr...@gmail.com wrote:
The thing to which promoters of immutable history are blind is that
while exact history record of development of particular feature might
be
Hi all,
My two cents:
I like phrase *commit jungle* and sometimes would like to revert some
commits or re-commit things a bit different. I also suppose that it
is not that rare when people commit something by mistake or something
which has not been tested enough. On the other hand my gut feeling
On 14 September 2012 16:57, Jacek Cała jacek.c...@gmail.com wrote:
Hi all,
My two cents:
I like phrase *commit jungle* and sometimes would like to revert some
commits or re-commit things a bit different. I also suppose that it
is not that rare when people commit something by mistake or
On Fri, Sep 14, 2012 at 05:08:53PM +0200, Michal Suchanek wrote:
On 14 September 2012 16:57, Jacek Cała jacek.c...@gmail.com wrote:
Hi all,
My two cents:
I like phrase *commit jungle* and sometimes would like to revert some
commits or re-commit things a bit different. I also suppose
On Fri, Sep 14, 2012 at 10:48 AM, Lluís Batlle i Rossell
vi...@viric.namewrote:
On Fri, Sep 14, 2012 at 05:08:53PM +0200, Michal Suchanek wrote:
On 14 September 2012 16:57, Jacek Cała jacek.c...@gmail.com wrote:
Hi all,
My two cents:
I like phrase *commit jungle* and sometimes
2012/9/14 Bill Burdick bill.burd...@gmail.com:
Sure, you could have named, alternate timelines and just choose which one to
make the default, each timeline forming a namespace for its branches and
tags and timelines could inherit from other timelines. That way you could
have rabasing without
On Fri, Sep 14, 2012 at 11:00 AM, Jacek Cała jacek.c...@gmail.com wrote:
2012/9/14 Bill Burdick bill.burd...@gmail.com:
Sure, you could have named, alternate timelines and just choose which
one to
make the default, each timeline forming a namespace for its branches and
tags and
2012/9/14 Bill Burdick bill.burd...@gmail.com:
Private commit tags sound a little less versatile than Git rebasing.
As said above, I don't really know how git rebasing works. Could you
shed more light on why it is more versatile than the simple private
tags?
Cheers,
Jacek
Bill Burdick wrote:
[...]
Who would want to have that? I think the Git community answers that.
Anyone who wants to have a cleaner presentation of history than what
actually happened. Being able to have a clean view without losing the
actual history sounds like a good trick, to me, and it
I'm not an expert on rebasing -- I've only done it a couple times, but as
far as I know, rebasing changes the timeline of a branch (potentially
radically). It lets you reorder commits, combine them together (squash
them), and break them into multiple commits (edit them). I've only done
Rather than comparing Fossil to Git, I compare it to Github, the Git
hosting service I'm sure you're all aware of. They've come a long way
extending Git to make it easier to use and add the integrated issue
tracking/wiki that Fossil has that Git alone doesn't have. Github
additionally has some
So, I think my description above shows why it's more versatile. Rebasing
is a tool that reorders, combines, and splits commits. A private tag might
be the end result of the editing. Rebasing could be done in fossil, there
just isn't a tool to do it (and Git's rebase tools are pretty involved).
Wes Freeman freeman@gmail.com wrote:
The fact of the matter, though, is you can choose whether you want to use
that feature of git or not; you're certainly not forced to use it.
Well, you can choose whether or not to use it locally. But once you share the
repo, anyone you pull from can use
On 14 September 2012 18:49, Mike Meyer m...@mired.org wrote:
Wes Freeman freeman@gmail.com wrote:
The fact of the matter, though, is you can choose whether you want to use
that feature of git or not; you're certainly not forced to use it.
Well, you can choose whether or not to use it
Thanks Bill for the explanation.
I see private tags as the end result of 'squash' rather than 'edit'.
If you have three commits A-B-C and decide to hide B, you will see
A-C. And then diff between C-A will show combined commits B+C against
A.
Regarding 'edit' and 'reorder', while 'edit' could be
Commit objects in Git are like manifests in Fossil, their id is the hash of
their contents, so squash, split, and reorder all end up creating new
commit objects with different ids. After a rebase, brach points to the new
most-recent commit produced. I'm pretty sure the old commit objects are
Michal Suchanek hramr...@gmail.com wrote:
On 14 September 2012 18:49, Mike Meyer m...@mired.org wrote:
Wes Freeman freeman@gmail.com wrote:
The fact of the matter, though, is you can choose whether you want to
use
that feature of git or not; you're certainly not forced to use it.
Well,
On 14 September 2012 19:03, Jacek Cała jacek.c...@gmail.com wrote:
Thanks Bill for the explanation.
I see private tags as the end result of 'squash' rather than 'edit'.
If you have three commits A-B-C and decide to hide B, you will see
A-C. And then diff between C-A will show combined commits
Bill Burdick wrote:
[...]
I think if you pull a rebased branch, you can get an error if the commit
your branch is no longer in the branch history, at which point you have to
decide what to do -- I think you can force the pull, if you want to. If
you made changes on the branch, you'd probably
2012/9/14 Michal Suchanek hramr...@gmail.com:
so you do a rebase so that your commits can be applied on top of F and
send then for review:
A-B-C-D-E-F-X'-Y'-Z'
If there are no conflicts between your changes and upstream this is
fine, otherwise you have to resolve them somehow, and upstream
On 14 September 2012 20:10, Jacek Cała jacek.c...@gmail.com wrote:
2012/9/14 Michal Suchanek hramr...@gmail.com:
so you do a rebase so that your commits can be applied on top of F and
send then for review:
A-B-C-D-E-F-X'-Y'-Z'
If there are no conflicts between your changes and upstream
I'm a faithful Fossil user and I have enjoyed its limitations compared
to Git because I consider them features. And pardon my commentary as I
typically lurk on the list rather than provide ongoing input to the
development.
If Git does all of this fancy stuff already, why not just use Git?
Rest assured that even if weird features like rebasing were to pollute
Fossil, no one would force you to use them :)
On Fri, Sep 14, 2012 at 1:42 PM, Michael L. Barrow mlbar...@barrow.mewrote:
I'm a faithful Fossil user and I have enjoyed its limitations compared
to Git because I consider
On 9/14/12 11:53 AM, Bill Burdick wrote:
Rest assured that even if weird features like rebasing were to
pollute Fossil, no one would force you to use them :)
But the size and complexity of the resulting application which is known
for being well-engineered could suffer...
--
michael at
On Fri, Sep 14, 2012 at 1:55 PM, Michael L. Barrow mlbar...@barrow.mewrote:
On 9/14/12 11:53 AM, Bill Burdick wrote:
Rest assured that even if weird features like rebasing were to
pollute Fossil, no one would force you to use them :)
But the size and complexity of the resulting application
Hello All,
I am newbie Fossil user and I wonder what is the reason to have two
different commands to show a checkout status: status and extras. In SCM
(Git, Svn) I have worked before there is single status command to show both
modified and new (i.e. not part of a checkout) files. Would not it be
On Thu, Sep 13, 2012 at 2:08 PM, Richard Hipp wrote:
It would be an interesting project to enhance Fossil so that it could
support UTF16 in addition to UTF8. What would be needed is an algorithm to
detect when a file was UTF16. (The BOM at the beginning of Kevin's example
ought to be a big
On Fri, Sep 14, 2012 at 5:46 AM, Richard Hipp d...@sqlite.org wrote:
Detection of embedded non-printing characters, especially U+, would be
nice.
Should we insist on a BOM at the beginning of the file?
I don't think a BOM should be mandatory, as it is not required by Unicode.
Another
On Fri, Sep 14, 2012 at 8:20 PM, Csaba Kos csaba@gmail.com wrote:
I think now would be a good time to discuss the possibility of a more
generic
text conversion framework, i.e. not only UTF16 to UTF8 but also SHIFT-JIS
to UTF8, and so on. Also CR+NL to NL conversion could be handled by
On Sat, Sep 15, 2012 at 1:21 PM, Scott Robison sc...@scottrobison.us wrote:
One thing I thought of yesterday but dismissed (and am now rethinking as a
result of your email) is maybe there should be a bit of meta-data that can
be attached to files to explicitly set their encoding. Having built
39 matches
Mail list logo
