Re: [fossil-users] how to move commits to a different branch
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 quite verbose commands. But I like the idea of having an edit command. Luca ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] minor: broken hyperlink in fossil web site
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 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] minor: broken hyperlink in fossil web site
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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to move commits to a different branch
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 given option, but perhaps --newbranch is too long. What about just --branch? Anyone else have an opinion on whether or not ``fossil edit'' should exist? It would be convenient, though, AFAICS, the only new functionality is branch moving. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to move commits to a different branch
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 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] trunk closed??
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 regularly...this is how I notice those harmless compiler warnings from time-to-time. I update on a few different machines, too, so I don't know how I would have made this mistake on multiple machines. For some reason, my fossil thinks I'm in this branch and therefore, there's no new updates: % fossil up Autosync: https://www.fossil-scm.org Round-trips: 4 Artifacts sent: 0 received: 54 Pull done, sent: 2775 received: 15790 ip: 67.18.92.124 --- checkout: fc871543374db6fac3053e70a6af205f23c4e751 2015-05-19 10:32:32 That check-in was originally on trunk and then got moved to the branch. You probably updated after the commit but before the move to a branch, which left you sitting on the branch. UTC tags: noDirPrompt comment: Remove unnecessary code from the fossil clean command. (user: drh) changes: None. Already up-to-date % fossil version This is fossil version 1.33 [fc87154337] 2015-05-19 10:32:32 UTC That's this closed branch: https://www.fossil-scm.org/index.html/info/fc871543374db6fa How would I have mixed myself up (on multiple machines) with this branch? Thanks! -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] trunk closed??
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 update it advances you to the tip of whatever branch your are currently on. If you want to be at the tip of trunk, you really do need to say fossil update trunk. We emphatically do NOT want Fossil second-guessing what branch you want to be on when you do fossil update without an argument. Oh, yeah! I had forgotten about the fossil up trunk trick! My alias has been updated again to specify fossil up trunk. -- D. Richard Hipp d...@sqlite.org Thanks! -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to move commits to a different branch
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? Anyone else have an opinion on whether or not ``fossil edit'' should exist? Thanks, Andy -- TAI64 timestamp: 400055687bc0 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] how to move commits to a different 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 long. Coming from git I'm used to a short command line, while fossil tend to be quite verbose commands. Fossil commands can be abbreviated to their shortest unambiguous prefix. Maybe the same could be done with options? Also, occurs to me that maybe the syntax could be fossil edit subcommand UUID ?OPTIONS? so you could have, for exmple, fsl ed n UUID NEWBRANCH (assuming you alias fossil to fsl) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] trunk closed??
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 currently on. If you want to be at the tip of trunk, you really do need to say fossil update trunk. We emphatically do NOT want Fossil second-guessing what branch you want to be on when you do fossil update without an argument. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] trunk closed??
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 just fossil update it advances you to the tip of whatever branch your are currently on. If you want to be at the tip of trunk, you really do need to say fossil update trunk. We emphatically do NOT want Fossil second-guessing what branch you want to be on when you do fossil update without an argument. for sure not. OTOH: although it has not (yet) happened to me, I can easily see that it is confusing to leave trunk if I *am* on trunk before the update and just issue `fossil up' (which most of the time for most of the users seems to mean move me forward on this branch (especially trunk) to the current, last version of this branch rather than move me to wherever my current checkout has evolved. at least that would be me guess...). so while fossil should not second-guess my intention and implement it, it very well _might_ second-guess my intention and notify me when I am probably doing something unintentional. as with assorted other things (e.g. empty checkin messages), should fossil not ask at this point (with a default of staying on the current branch)? the scenario would be * I am on branch X * I issue `fossil up' w/o argument * `fossil' notes that this will move me to a different branch since someone else has transplanted the last checkin to a different branch * fossil asks if I do want to proceed or simply stay where I am. it should happen seldom enough in order not to annoy anybody if such a question is issued. thx/j -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] WARNING: multiple open leaf check-ins on trunk:
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 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] WARNING: multiple open leaf check-ins on trunk:
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) UNICODE_COMMAND_LINE Doing a FOSSIL UP TRUNK command gave me this today: WARNING: multiple open leaf check-ins on trunk: (1) 2015-05-29 17:48:57 [eba9fa6147] (current) (2) 2014-11-05 13:36:22 [91ef16c613] Trying the same with this previous fossil version I used: This is fossil version 1.32 [6c40678e91] 2015-03-14 13:20:34 UTC Compiled on Apr 11 2015 16:16:04 using msc-18.00 (32-bit) SQLite 3.8.8 2015-02-25 14:25:31 6d132e7a22 Schema version 2015-01-24 zlib 1.2.8, loaded 1.2.8 SSL (OpenSSL 1.0.2a 19 Mar 2015) UNICODE_COMMAND_LINE gives no problems! Is my repo corrupt or what’s wrong with the new (or the old) version? My timeline looks fine. Thanks.___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] WARNING: multiple open leaf check-ins on trunk:
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 https://www.fossil-scm.org/index.html/info/91ef16c613 Perhaps it's something in your local repository? Andy -- TAI64 timestamp: 40005568ae73 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] WARNING: multiple open leaf check-ins on trunk:
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, but it will certainly merge the two leaves and it should show up in your timeline. As for closing the older trunk, I thought about it, but I'm not sure in what ways it would affect the operation of the various fossil commands? That's a good question. That particular leaf will no longer show up in the open leaves report. It will not be possible to commit changes against the closed leaf (without a bit of extra work). Not sure what else might be implied here. Would they treat it the same as before, or because it's close it would be considered differently, e.g., being excluded from certain reports, etc.? It would certainly cease to be listed as a fork. Andy -- TAI64 timestamp: 40005568ef5b ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] WARNING: multiple open leaf check-ins on trunk:
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 given is not already a branch), or commits against that branch if it already exists. Keep in mind that a checkin must go against the current checkout that you are at in your repository. Even if you give it --branch, the parent for the checkin will still be your current node, not the tip of some other branch that might exist. So, if you make changes to trunk, use --branch NAME to checkin and then do more work on trunk and again use --branch NAME when you checkin, they will have the same ``branch'' tag by the name of NAME, but in the timeline, there will not be a direct lineage from the first checkin to the second on the ``branch.'' So, to address your last statement, ``[--branch] commits against that branch if it already exists'' it does, however, perhaps not in the way you might think. It does not magically update your checkout to the tip of the named branch if it exists. It simply starts a new named fork with the branch name given, even if the same name already exists. Does that help? Thanks, Andy -- TAI64 timestamp: 40005568ffc8 ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] trunk closed??
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 update to the actual branch you were on to start with, which is what the user is (rightly or wrongly) expecting. Silently changing branches without a loud warning does not make sense. Because I switch branches all the time, I do every now and then fossil status and look at on what branch I am. So that is not a major problem for my current work habits (because I spot it early). But I can see, that a warning would be an improvment, if the current branch changes silently, otherwise. rolf ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] WARNING: multiple open leaf check-ins on trunk:
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 not already a branch), or commits against that branch if it already exists. What I now understand (from what happened, and your explanation) is that --branch simply creates a new branch with whatever name you give it (even if it already exists), without warning that this will cause a (most likely) unintended 'fork'. Again, something that may need revising, perhaps with the addition of a warning. 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'm pretty my team doesn't have duplicate branch names because our policy requires us to include either a Requirement Number, a Change Request Number or Release ID as part of branch names.) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] WARNING: multiple open leaf check-ins on trunk:
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 existing tag or branch name, with a --force option if you know what you're doing. :) [Grin because I hose myself most often when I'm sure I'm doing the right thing.] -- Thanks, DougF (KG4LMZ) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] getting rid of warning can't open /dev/null...
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 www.fossil-scm.org website does.) Unfortunately, I have no idea how to that. mkdir /jail/dev mknod /jail/dev/null c 1 3 mknod /jail/dev/urandom c 1 9 While you're at it, you may optionally do: mkdir /jail/etc cp /etc/localtime /jail/etc so your timeline isn't locked to UTC. You will also need to use the web administration interface to configure the timeline to show in local time. This should be documented on the Fossil website someplace Yes, please. -- Andy Goth | andrew.m.goth/at/gmail/dot/com signature.asc Description: OpenPGP digital signature ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] WARNING: multiple open leaf check-ins on trunk:
(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: https://www.dropbox.com/s/ozzicm164dc2o0d/fork.png?dl=0): 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?) 91ef is trunk, and e096 is trunk, but there is no direct link between them, only through d137. Is this considered a fork even though there is no duplicate trunk timeline? It’s more like a ‘discontinuous‘ trunk. What I wanted to do at the time was to make d137 disappear completely. But, (if I’m not mistaken, based on advice I had received possibly on this list – at least the way I had understood it), moved it to branch ‘mistake’ to make it invisible from trunk. So, now I’m stuck with a warning? Is there a way to re-connect 91ef to e096 without going via d137? Or, even to re-instate d137 as trunk, if no better way? Thank you. -Original Message- From: Richard Hipp Sent: Friday, May 29, 2015 9:24 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] WARNING: multiple open leaf check-ins on trunk: 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 1.2.8, loaded 1.2.8 SSL (OpenSSL 1.0.2a 19 Mar 2015) UNICODE_COMMAND_LINE Doing a FOSSIL UP TRUNK command gave me this today: WARNING: multiple open leaf check-ins on trunk: (1) 2015-05-29 17:48:57 [eba9fa6147] (current) (2) 2014-11-05 13:36:22 [91ef16c613] Bring up fossil ui then move your browser to http://localhost:8080/timeline?c=2014-11-05 and you'll see the fork. This is a new feature of Fossil, not a bug. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] trunk closed??
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 ended up on some other branch. 3. It has caused real-world wasted time for me and for others that I support. 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 update to the actual branch you were on to start with, which is what the user is (rightly or wrongly) expecting. Silently changing branches without a loud warning does not make sense. A branch is a symbolic idea and our situational awareness is attached to the branch name, not to some abstract and non-intuitive notion of location regarding attached nodes on a DAG. In short a very loud warning is needed, no matter what path you take. Just my $0.02. On Fri, May 29, 2015 at 9:05 AM, j. van den hoff veedeeh...@googlemail.com wrote: 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 just fossil update it advances you to the tip of whatever branch your are currently on. If you want to be at the tip of trunk, you really do need to say fossil update trunk. We emphatically do NOT want Fossil second-guessing what branch you want to be on when you do fossil update without an argument. for sure not. OTOH: although it has not (yet) happened to me, I can easily see that it is confusing to leave trunk if I *am* on trunk before the update and just issue `fossil up' (which most of the time for most of the users seems to mean move me forward on this branch (especially trunk) to the current, last version of this branch rather than move me to wherever my current checkout has evolved. at least that would be me guess...). so while fossil should not second-guess my intention and implement it, it very well _might_ second-guess my intention and notify me when I am probably doing something unintentional. as with assorted other things (e.g. empty checkin messages), should fossil not ask at this point (with a default of staying on the current branch)? the scenario would be * I am on branch X * I issue `fossil up' w/o argument * `fossil' notes that this will move me to a different branch since someone else has transplanted the last checkin to a different branch * fossil asks if I do want to proceed or simply stay where I am. it should happen seldom enough in order not to annoy anybody if such a question is issued. thx/j -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] WARNING: multiple open leaf check-ins on trunk:
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 commands. Add fossil leaves -multiple, for finding multiple leaves on the same branch. Added fork warning to be issued if sync produced a fork https://www.fossil-scm.org/index.html/help?cmd=update https://www.fossil-scm.org/index.html/help?cmd=status https://www.fossil-scm.org/index.html/help?cmd=leaves -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] WARNING: multiple open leaf check-ins on trunk:
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 1.2.8, loaded 1.2.8 SSL (OpenSSL 1.0.2a 19 Mar 2015) UNICODE_COMMAND_LINE Doing a FOSSIL UP TRUNK command gave me this today: WARNING: multiple open leaf check-ins on trunk: (1) 2015-05-29 17:48:57 [eba9fa6147] (current) (2) 2014-11-05 13:36:22 [91ef16c613] Bring up fossil ui then move your browser to http://localhost:8080/timeline?c=2014-11-05 and you'll see the fork. This is a new feature of Fossil, not a bug. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] WARNING: multiple open leaf check-ins on trunk:
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 of thing. As far as I can tell, what happened was you made a change which resulted in d137. You didn't like d137, so you moved it to a branch. Then you decided to continue development, but you needed trunk, so while you were still in the mistake branch, you backed out the changed and committed the change with --branch trunk to place the commit on trunk. But this action resulted in 2 leaves on trunk. What you probably should have done instead was simply move the mistake to the branch, then proceed with development on trunk at 91ef and make new commits against 91ef. Then e096 would have been a child of 91ef. Is there a way to re-connect 91ef to e096 without going via d137? Or, even to re-instate d137 as trunk, if no better way? If you want to attach, you can simply use ``fossil merge'' and it will see that there are multiple leaves on trunk and try to merge them. Or you could probably just close 91ef and make it a Closed-leaf which will make it not be considered any longer. (with UI edit 91ef and choose the Close option). Thanks, Andy -- TAI64 timestamp: 40005568d67c ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
