Re: [fossil-users] State of tkt-hook-change branch

2013-12-20 Thread Jan Nijtmans
2013/12/16 Jan Nijtmans jan.nijtm...@gmail.com: @Joe/Richard: Any reason to hold back merging this to trunk? If not, I'm happy to do the merge. No-one objected, so merged to trunk now. Happy Christmas days to all! Jan Nijtmans ___

[fossil-users] fossil import timestamp mangling

2013-12-20 Thread David Given
fossil import --git ignores the timezone field on timestamps. I have this in the fast import dump: mark :4 author David Given d...@cowlark.com 1309983972 +0100 committer David Given d...@cowlark.com 1309983972 +0100 data 17 Initial checkin. ...but in the fossil repo it actually ends up being:

Re: [fossil-users] fossil import timestamp mangling

2013-12-20 Thread Ron Wilson
On Fri, Dec 20, 2013 at 10:53 AM, David Given d...@cowlark.com wrote: fossil import --git ignores the timezone field on timestamps. I have this in the fast import dump: mark :4 author David Given d...@cowlark.com 1309983972 +0100 committer David Given d...@cowlark.com 1309983972 +0100 data

Re: [fossil-users] fossil import timestamp mangling

2013-12-20 Thread David Given
On 20/12/13 16:15, Ron Wilson wrote: [...] Interesting. I would have thought all time stamps in git would, like Fossil, be seconds from the epoch. (It was originally developed by the Linux kernel core team.) So would I. I suppose it *is* seconds since epoch... but they don't define which

Re: [fossil-users] fossil import timestamp mangling

2013-12-20 Thread Jan Nijtmans
2013/12/20 David Given d...@cowlark.com: (Sorry, I accidentally committed to trunk and then had to undo. It'd be nice if 'fossil branch new' would either change the current branch or at the very least print a warning that the current branch hadn't changed.) In fossil that's not a problem: You

Re: [fossil-users] fossil import timestamp mangling

2013-12-20 Thread David Given
On 20/12/13 22:41, Jan Nijtmans wrote: [...] In fossil that's not a problem: You can always move the commit to another branch, even after you already committed it. Oh, yeah, I'd forgotten you could do that. Admittedly, I only noticed after I'd done the sync, and wanted to fix things as quickly

[fossil-users] Parent of the very first checkin?

2013-12-20 Thread David Given
hg has a concept of the changeset with uuid . This is the empty changeset, and is equivalent to the parent of the very first checkin. Checking out this changeset will give you an empty repository; checking in with this as the parent will give you a new tree,

Re: [fossil-users] Parent of the very first checkin?

2013-12-20 Thread Richard Hipp
Every repository as an initial check-in which is empty. But it always has a different SHA1 hash, since it also includes the timestamp from when the repository was created. Example: http://www.fossil-scm.org/fossil/info/a28c83647d And the actual text of the manifest artifact:

Re: [fossil-users] Parent of the very first checkin?

2013-12-20 Thread Richard Hipp
On Fri, Dec 20, 2013 at 7:27 PM, David Given d...@cowlark.com wrote: On 21/12/13 00:05, Richard Hipp wrote: Every repository as an initial check-in which is empty. But it always has a different SHA1 hash, since it also includes the timestamp from when the repository was created. Is it

Re: [fossil-users] Parent of the very first checkin?

2013-12-20 Thread Andy Bradford
Thus said Richard Hipp on Fri, 20 Dec 2013 19:05:07 -0500: http://www.fossil-scm.org/fossil/info/a28c83647d Is there a command line option that will find this artifact? I thought perhaps the root:trunk symbolic name would find it, but I was wrong. It finds

Re: [fossil-users] Parent of the very first checkin?

2013-12-20 Thread B Harder
If I understand what you're looking for (first empty commit?), when I asked this question some time ago, somebody suggested I just tag it myself. Simple solution, Just Works. On Dec 20, 2013 8:54 PM, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Richard Hipp on Fri, 20 Dec 2013

Re: [fossil-users] Parent of the very first checkin?

2013-12-20 Thread Matt Welland
How is what you are looking for different from checking out the very first node in your tree, the initial empty check-in? I used to do what you are describing quite extensively when I used monotone. But with monotone it was easy to sync a subset of branches or revision trees from one repo to