[fossil-users] Incorrect branch content on import
Hi List I'm trying to move my dhcpcd git repository [1] to fossil [2]. While it works for the most part, it seems that the branches called trunk and dhcpcd-5 have the same commits, which is just wrong. I have successfully done a git export | git import to a new repository [3] to see if it's a git problem, but the end product is fine. Lastly, I did a fossil export to git [4] which now exhibits the same problems. So I must assume the problem is in fossil. I've tried versions 1.26 and 1.27. Is this something easily fixable? Can I provide any more help debugging it? One other thing of note, it seems that on import all commiters are me. While this is true, I would rather record the author on the git commit. Is this posible? Thanks Roy [1] http://roy.marples.name/cgi-bin/gitweb.cgi?p=dhcpcd.git;a=summary [2] http://roy.marples.name/fossil/dhcpcd/ [3] http://roy.marples.name/cgi-bin/gitweb.cgi?p=dhcpcd-test/.git;a=summary [4] http://roy.marples.name/cgi-bin/gitweb.cgi?p=dhcpcd-new/.git;a=summary ___ 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] Incorrect branch content on import
On 21/12/2013 21:11, Roy Marples wrote: I'm trying to move my dhcpcd git repository [1] to fossil [2]. While it works for the most part, it seems that the branches called trunk and dhcpcd-5 have the same commits, which is just wrong. By adding a commit to the dhcpcd-5 branch in git, exporting and then importing into fossil it now seems to work. I can live with that, as the commit is kinda valid using a more recent compiler than when the branch was done. I did this in different repos - dhcpcd-test, so the initial links are still valid incase anyone wants to debug this. I'll be doing that in the main repo tomorrow so I can move forward, but I'll make a backup first and post the link here incase someone really does want to fix it. I also exported it back to git and aside from committer name and the branch names having _ instead of say a . or a - it looks good. I assume the branch renaming is some kind of bug because the branch names look fine in fossil itself. A less important issue is that there seems to be no tie between trunk and git master in the fresh export (ie the git repo looks blank aside from the branch content). Lastly, before I dive into the fossil code to try and address the branch name export issue, does anyone know how fossil handles user names on import/export? Ideally I'd like to preserve the My Name m...@name.org in my current git repo @ import and also show this @ export. Thanks Roy ___ 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] Incorrect branch content on import
On 22/12/2013 0:55, Roy Marples wrote: On 21/12/2013 21:11, Roy Marples wrote: I'm trying to move my dhcpcd git repository [1] to fossil [2]. While it works for the most part, it seems that the branches called trunk and dhcpcd-5 have the same commits, which is just wrong. By adding a commit to the dhcpcd-5 branch in git, exporting and then importing into fossil it now seems to work. So basically the error happened because once the dhcpd-5 branch was made there were no commits in it. Hope this helps someone fixing it. Roy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Export artifact to archive?
Hi List Can fossil create an archive (tarball, zip file, etc) from a given artifact id WITHOUT using the web interface? Something like this is what I need: $ fossil archive ?ID | bzip2 distribution-version.tar.bz2 Thanks Roy ___ 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] Export artifact to archive?
On 03/01/2014 16:41, Lluís Batlle i Rossell wrote:
On Fri, Jan 03, 2014 at 04:36:26PM +, Roy Marples wrote:
Hi List
Can fossil create an archive (tarball, zip file, etc) from a given
artifact id WITHOUT using the web interface?
Something like this is what I need:
$ fossil archive ?ID | bzip2 distribution-version.tar.bz2
Hi,
fossil tarball.
This works well, thanks.
To use an alternate compression I can simply gunzip | bzip2 as this
Makefile snippet shows
FOSSILID?= current
dist:
fossil tarball --name ${DISTPREFIX} ${FOSSILID} ${DISTFILEGZ}
gunzip -c ${DISTFILEGZ} | bzip2 ${DISTFILE}
rm ${DISTFILEGZ}
Thanks
Roy
___
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] Export artifact to archive?
On 03/01/2014 16:42, Richard Hipp wrote: On Fri, Jan 3, 2014 at 11:36 AM, Roy Marples r...@marples.name wrote: Hi List Can fossil create an archive (tarball, zip file, etc) from a given artifact id WITHOUT using the web interface? Something like this is what I need: $ fossil archive ?ID | bzip2 distribution-version.tar.bz2 http://www.fossil-scm.org/fossil/help?cmd=tarball [2] http://www.fossil-scm.org/fossil/help?cmd=zip [3] My thanks. I obviously did not read the command line output regarding the -a option to help. I don't know how that could be improved either, other than removing the -a option and just showing all the commands :) Thanks Roy ___ 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] Painful team interaction with fossil, how to improve?
Hi On 13/02/2014 15:24, Baptiste Daroussin wrote: In particular to interact with the submitter. I have found no way to: 1/ send a mail when new ticket is created (yes we can follow via rss feed, but a mail is way nicer) I don't have a huge problem with RSS as it looks to be possible to subscribe to all ticket changes which is great for me as a repo admin. It's also possible subscribe to an individual ticket RSS. However, using the default skin I don't see an easy way to do this. This makes it hard to use. Would it be possible to add a RSS button to the timeline and the ticket pages? Thinking about it, each page could have one and the link is filtered based on the filtering for the page. Roy ___ 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] Painful team interaction with fossil, how to improve?
On 18/02/2014 14:40, Roy Marples wrote:
I don't have a huge problem with RSS as it looks to be possible to
subscribe to all ticket changes which is great for me as a repo admin.
It's also possible subscribe to an individual ticket RSS.
However, using the default skin I don't see an easy way to do this.
This makes it hard to use.
Would it be possible to add a RSS button to the timeline and the
ticket pages? Thinking about it, each page could have one and the link
is filtered based on the filtering for the page.
Here is a patch which adds a RSS feed icon after the ticket uuid.
Probably not the best way of doing it, but I couldn't think of another
way which would allow the user to use a different icon to match their
skin.
Maybe just RSS Feed as a menu item would be better?
Thanks
RoyAdd a RSS feed icon to the ticket view.
--- src/tktsetup.c.orig 2014-02-20 10:23:13.0 +
+++ src/tktsetup.c
@@ -437,13 +437,13 @@ static const char zDefaultView[] =
@ table cellpadding=5
@ trtd class=tktDspLabelTicketnbsp;UUID:/td
+@ td class='tktDspValue' colspan='3'$tkt_uuid
@ th1
@ if {[hascap s]} {
-@ html td class='tktDspValue' colspan='3'$tkt_uuid
-@ html ($tkt_id)/td/tr\n
-@ } else {
-@ html td class='tktDspValue' colspan='3'$tkt_uuid/td/tr\n
+@ html nbsp($tkt_id)
@ }
@ /th1
+@ nbsp;a href=$baseurl/timeline.rss?tkt=$tkt_uuidimg src=data:image/png;base64,iVBORw0KGgoNSUhEUg4OCAYfSC3RBGdBTUEAAK/INwWK6QAAABl0RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAAJDSURBVHjajJJNSBRhGMd/887MzrQxRSLbFuYhoUhEKsMo8paHUKFLdBDrUIdunvq4RdClOq8Hb0FBSAVCUhFR1CGD/MrIJYqs1kLUXd382N356plZFOrUO/MMz/vO83+e93n+f+1zF+kQBoOQNLBJg0CTj7z/rvWjGbEOIwKp9O7WkhtQc/wMWrlIkP8Kc1lMS8eyFHpkpo5SgWCCVO7Z5JARhuz1Qg29fh87u6/9VWL1/SPc4Qy6n8c0FehiXin6dcCQaylDMhqGz8ydS2hKkmxNkWxowWnuBLHK6G2C8X6UJkBlxUmNqLYyNbzF74QLDrgFgh9LLE0NsPKxjW1Hz2EdPIubsOFdH2HgbwAlC4S19dT13o+3pS+vcSfvUcq9YnbwA6muW9hNpym/FWBxfh0CZkKGkPBZeJFhcWQAu6EN52QGZ/8prEKW+cdXq0039UiLXhUYzdjebOJQQI30UXp6mZn+Dtam32Afu0iyrgUvN0r+ZQbr8HncSpUVJfwRhBWC0hyGV8CxXBL5SWYf9sYBidYLIG2V87/ifVjTWAX6AlxeK2C0X8e58hOr/Qa2XJ3iLMWxB1h72tHs7bgryzHAN2o2gJorTrLxRHVazd0o4TXiyV2Yjs90uzauGvvppmqcLjwmbZ3V7BO2HOrBnbgrQRqWUgTZ5+Snx4WeKfzCCrmb3axODKNH+vvUyWjqyK4DiKQ0eXSpFsgVvLJQWpH+xSpr4otg/HI0TR/t97cxTUS+QxIMRTLi/9ZYJPI/AgwAoc3W7ZrqR2IASUVORK5CYII alt=RSS feed icon //a
+@ /tr/td
@ trtd class=tktDspLabelTitle:/td
@ td class=tktDspValue colspan=3
@ $title
___
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] Painful team interaction with fossil, how to improve?
On 20/02/2014 15:07, Ron Wilson wrote: On Thu, Feb 20, 2014 at 6:56 AM, Roy Marples r...@marples.name wrote: Here is a patch which adds a RSS feed icon after the ticket uuid. Probably not the best way of doing it, but I couldn't think of another way which would allow the user to use a different icon to match their skin. Maybe just RSS Feed as a menu item would be better? From my experience, the RSS icon is a very common way to provide a way to subscribe to a feed. Interesting that you need to make an actual source code change. I would have expected it could be changed in the header. The source code change just affects the default HTML for the ticket view. Basically making the default view more useable. You can of course edit it in via the www interface. I wouldn't know how to put it into the header. Maybe some of this tc1 code to toggle it? Roy ___ 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] html file - cannot compute difference between binary files
On 10/03/2014 22:24, Richard Hipp wrote: The diff-generator in Fossil is unable to cope with lines longer than 8192 bytes. That could be changed. (It's a #define, though there are adverse consequences for making it too large.) But is a diff on a file with huge lines like that really useful? Would a human be able to understand such a diff? That would depend on how the diff is presented. As two long lines? No, I doubt a human could. But if you present the diff as two wrapped lines side by side diff A | diff B and wrapped each at say 35 chars with a clear border and space down the middle and highlighted using colour each difference I can see that working even on a 80 char wide console. But equally, the diff command is used to present a difference between files. A human might not care about understanding it, as long as patch(1) does. Roy ___ 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] GitHub-style template
On 17/03/2014 16:22, ma...@include-once.org wrote: It's nowhere near finished, but here's a github-simulating layout: http://fossil.include-once.org/hybrid7/ Barely holds together, and it's not yet working in Firefox. But includes fx_search support, my th1x functions for the language bar and file box, and comes with built-in code highlighting. Requires fossil-search-table.php run beforehand for fx_search/_stats. I plan on using this to not be nagged about switching to actual git+github. Can be downloaded here as usual: http://fossil.include-once.org/fossil-skins/ Looks really nice! Keep up the good work. Roy ___ 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] Proposed improvement to inherited privileges subscripts.
On Saturday 27 Sep 2014 11:09:44 Andy Bradford wrote: Thus said Stephan Beal on Sat, 27 Sep 2014 10:02:50 +0200: font-family: monospace; still trying to decide if that is more readable, though. Not yet convinced. I tried it and I didn't think it improved anything, and in fact, it made it slightly more difficult to read the character (at least for me). So, any concensus on what it should be? Is this it, or something else? http://www.fossil-scm.org/index.html/info/a6e8e7004d4e53025c592c5ab391386a39 941edf The whole problem with that view for me is that the font is a lot smaller than unifed view, which I prefer and fine more readable on the whole anyway. Roy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil ui file view broken
Hi Running fossil ui on any repo (using 1.29 and 1.30), all the CSS looks disabled and the file link fails to work - no treeview or flat view. Any ideas on how to fix? Roy ___ 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] Improving Fossil's Look
On 2015-02-17 23:43, Richard Hipp wrote: I have switched the default Fossil repo over to using the San Francisco Modern skin. Everybody seems to think it looks a lot better, and I agree. I like the look, but why the fixed width? I like the flexible width of the original skin more. Roy ___ 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] fossil ui file view broken
Hi Richard On 22/01/2015 22:41, Richard Hipp wrote: Running fossil ui on any repo (using 1.29 and 1.30), all the CSS looks disabled and the file link fails to work - no treeview or flat view. Any ideas on how to fix? No ideas off-hand, since nobody else is seeing this problem. Do you have further clues on how to repro the problem? Well, I turned on some more boxes to test with and I can only replicate the problem on Gentoo/Linux (using my http://roy.marples.name/projects/dhcpcd fossil repo as a test) using any fossil version in portage. Date stamps are 2013094349 and 20140612172556. On NetBSD it works fine. Which is odd as two NetBSD devs had the same issue looking at the sqlite3 repo. I'll try and get more data. Roy ___ 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] two questions abut git import
On Monday 29 Dec 2014 06:30:58 Richard Hipp wrote: Unfortunately, there is no way to do this for every check-in all at once. You would have to go through and create separate tags for each check-in. There is probably a way to script this. But it would be better to change the names in git prior to import, probably. Or, run the git-fast-export text through a sed script that makes the change prior to sending into fossil import. When I converted my repos from git to fossil I changed the names in the git- fast-export text via sed (of course doing a diff to ensure nothing else was changed). Roy ___ 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] Missing timeline graph above 36 timeline items (?!)
On Monday 16 Mar 2015 12:07:58 Richard Hipp wrote: On 3/16/15, Richie Adler richiead...@gmail.com wrote: After the latest upgrades, I've been unable to see the timeline graphs if I have more than 36 items in the timeline. The space for the graph remains, but nothing is drawn. The weirdest thing is that I have reverted to old versions and I'm still unable to see the full graph! I can see it in the Fossil site which is running the same version, though... In another thread (fossil ui not working with recent chrome browser) there are reports of truncated pages when running on Windows. But so far, none of the developers have been able to reproduce the problem. If you can show us how to repro the problem, we'll fix it right away. I reported similar a while ago: http://comments.gmane.org/gmane.comp.version-control.fossil-scm.user/19356 It looks very similar to this issue here. Roy ___ 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] Justification for two-step mv and rm
On Tuesday 03 Mar 2015 16:22:40 Richard Hipp wrote: On 3/3/15, Warren Young w...@etr-usa.com wrote: Is there a good reason that “fossil mv” and “fossil rm” must be followed by OS-level mv and rm commands? I miss the behavior of Subversion which made these into a single step. When I have suggested changing this, I got push back that the change will break existing scripts. Add flag -f to mv and rm to do this? Allows the desired feature and is sort of similar to CVS fossil mv -f file1 file2 fossil rm -f file1 file2 Roy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil export handling of trunk differs from import
Hi List!
When importing a git fast import file, the master branch is silently
changed to trunk, to match the fossil default.
However, when exported back out the reverse conversion does not apply.
This is not good, because fossil is effectively re-writing history.
But what is worse is that the export does not match the import I'm
striving to get out pretty much exactly what I put in.
Patch attached to fix this.
Roy
Index: src/export.c
==
--- src/export.c
+++ src/export.c
@@ -611,11 +611,12 @@
bag_insert(, ckinId);
db_bind_int(, ":rid", ckinId);
db_step();
db_reset();
-if( zBranch==0 ) zBranch = "trunk";
+/* fossil trunk is git master. */
+if( zBranch==0 || fossil_strcmp(zBranch, "trunk") == 0 ) zBranch =
"master";
zMark = mark_name_from_rid(ckinId, _mark);
printf("commit refs/heads/");
print_ref(zBranch);
printf("\nmark %s\n", zMark);
free(zMark);
___
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] Branch and Tag names in export
On 09/02/2017 15:06, Joerg Sonnenberger wrote:
> On Thu, Feb 09, 2017 at 01:47:43PM +0000, Roy Marples wrote:
>> Hi List!
>>
>> In fossil I have this: branch-1.7, tag-1.2
>> But when I export I get this: branch_1_7, tag_1_2
>>
>> Why is the name mangled like so? Surely the original names should be
>> preserved.
>
> It's currently preserving only alphanumeric characters. Noone ever
> implemented the full sanitation requirement of git.
Attached is a patch with implements sanity checking as per
https://git-scm.com/docs/git-check-ref-format
Applies with my prior patch.
Roy
Index: src/export.c
==
--- src/export.c
+++ src/export.c
@@ -161,10 +161,68 @@
printf(" %s <%s>", zName, zEmail);
free(zName);
free(zEmail);
db_reset();
}
+
+#define REFREPLACEMENT '_'
+
+/*
+** Output a sanitized git named reference.
+** https://git-scm.com/docs/git-check-ref-format
+** This implementation assumes we are only printing
+** the branch or tag part of the reference.
+*/
+static void print_ref(const char *zRef){
+ char *zEncoded = mprintf("%s", zRef);
+ int i, w;
+ if (zEncoded[0]=='@' && zEncoded[1]=='\0'){
+putchar(REFREPLACEMENT);
+return;
+ }
+ for(i=0, w=0; zEncoded[i]; i++, w++){
+if( i!=0 ){ /* Two letter tests */
+ if( (zEncoded[i-1]=='.' && zEncoded[i]=='.') ||
+ (zEncoded[i-1]=='@' && zEncoded[i]=='{') ){
+zEncoded[w]=zEncoded[w-1]=REFREPLACEMENT;
+continue;
+ }
+ if( zEncoded[i-1]=='/' && zEncoded[i]=='/' ){
+w--; /* Normalise to a single / by rolling back w */
+continue;
+ }
+}
+/* No control characters */
+if( (unsigned)zEncoded[i]<0x20 || zEncoded[i]==0x7f ){
+ zEncoded[w]=REFREPLACEMENT;
+ continue;
+}
+switch( zEncoded[i] ){
+ case ' ':
+ case '^':
+ case ':':
+ case '?':
+ case '*':
+ case '[':
+ case '\\':
+zEncoded[w]=REFREPLACEMENT;
+ break;
+}
+ }
+ /* Cannot begin with a . or / */
+ if( zEncoded[0]=='.' || zEncoded[0] == '/' ) zEncoded[0]=REFREPLACEMENT;
+ if( i>0 ){
+i--; w--;
+/* Or end with a . or / */
+if( zEncoded[i]=='.' || zEncoded[i] == '/' ) zEncoded[w]=REFREPLACEMENT;
+/* Cannot end with .lock */
+if ( i>4 && strcmp((zEncoded+i)-5, ".lock")==0 )
+ memset((zEncoded+w)-5, REFREPLACEMENT, 5);
+ }
+ printf("%s", zEncoded);
+ free(zEncoded);
+}
#define BLOBMARK(rid) ((rid) * 2)
#define COMMITMARK(rid) ((rid) * 2 + 1)
/*
@@ -547,26 +605,22 @@
const char *zSecondsSince1970 = db_column_text(, 0);
int ckinId = db_column_int(, 1);
const char *zComment = db_column_text(, 2);
const char *zUser = db_column_text(, 3);
const char *zBranch = db_column_text(, 4);
-char *zBr;
char *zMark;
bag_insert(, ckinId);
db_bind_int(, ":rid", ckinId);
db_step();
db_reset();
if( zBranch==0 ) zBranch = "trunk";
-zBr = mprintf("%s", zBranch);
-for(i=0; zBr[i]; i++){
- if( !fossil_isalnum(zBr[i]) ) zBr[i] = '_';
-}
zMark = mark_name_from_rid(ckinId, _mark);
-printf("commit refs/heads/%s\nmark %s\n", zBr, zMark);
+printf("commit refs/heads/");
+print_ref(zBranch);
+printf("\nmark %s\n", zMark);
free(zMark);
-free(zBr);
printf("committer");
print_person(zUser);
printf(" %s +\n", zSecondsSince1970);
if( zComment==0 ) zComment = "null comment";
printf("data %d\n%s\n", (int)strlen(zComment), zComment);
@@ -637,30 +691,24 @@
" FROM tagxref JOIN tag USING(tagid)"
" WHERE tagtype=1 AND tagname GLOB 'sym-*'"
);
while( db_step()==SQLITE_ROW ){
const char *zTagname = db_column_text(, 0);
-char *zEncoded = 0;
int rid = db_column_int(, 1);
char *zMark = mark_name_from_rid(rid, _mark);
const char *zSecSince1970 = db_column_text(, 2);
const char *zUser = db_column_text(, 3);
-int i;
if( rid==0 || !bag_find(, rid) ) continue;
zTagname += 4;
-zEncoded = mprintf("%s", zTagname);
-for(i=0; zEncoded[i]; i++){
- if( !fossil_isalnum(zEncoded[i]) ) zEncoded[i] = '_';
-}
-printf("tag %s\n", zEncoded);
-printf("from %s\n", zMark);
+printf("tag ");
+print_ref(zTagname);
+printf("\nfrom %s\n", zMark);
free(zMark);
printf("tagger");
print_person(zUser);
printf(" %s +\n", zSecSince1970);
printf("data 0\n");
-fossil_free(zEncoded);
}
db_finalize();
if( markfile_out!=0 ){
FILE *f;
___
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] fossil export handling of trunk differs from import
On 10/02/17 17:52, Roy Marples wrote: > On 09/02/2017 21:42, Roy Marples wrote: >> When importing a git fast import file, the master branch is silently >> changed to trunk, to match the fossil default. >> However, when exported back out the reverse conversion does not apply. >> >> This is not good, because fossil is effectively re-writing history. >> But what is worse is that the export does not match the import I'm >> striving to get out pretty much exactly what I put in. > > The silent branch renaming is problematic, but solvable. > Both fossil and git work fine without a master or trunk branch. > It is just a question of changing the defaults. I propose the following: > > Without any options, both import and export preserve the original naming > scheme. However, we use the provided options to handle preference. > > fossil import --rename-master trunk > fossil export --rename-trunk master > > This would allow a bi-directional bridge where the default trunk name is > respected at both ends. It would also allow the crazy situation where > you have both trunk AND master branches. This has now been done in the roy-export branch. Testing welcome. One issue with my changes is that when a git repo imports to a new fossil database, there is no trunk branch or tag (visible from the ui at least) but when we try to create a trunk branch fossil complains it already exists. Another issue (but this exists before my changes) is the rename trunk feature, probably related to the above issue: $ ./fossil import --git --rename-trunk master x.fossil x Rebuilding repository meta-data... 100.0% complete... SQLITE_ERROR: no such table: vfile ./fossil: no such table: vfile SELECT 1 FROM vfile WHERE pathname='manifest' $ So my question is, has the --rename-trunk feature ever worked and can fossil work without the trunk branch at all to allow a new one to be created? Roy ___ 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] fossil export handling of trunk differs from import
On 10/02/2017 19:10, Joe Mistachkin wrote: > > Roy Marples wrote: >> >> fossil import --rename-master trunk >> fossil export --rename-trunk master >> > > As a matter of my personal preferences and taste, I really like the > idea of NOT doing "magic branch renaming" by default and adding the > above new options. > > What kind of backward compatibility issues might we face with those > changes? Import and export are used in three possible scenarios: 1) Import into fossil, discard old repository 2) Export from fossil, discard fossil repository 3) Fossil is one end of a bi-directional bridge The first two cases are one shot, thus there is no backwards compat to be concerned about. The third case should also not be a problem for existing setups because master being renamed to trunk has already happened, so master doesn't exist here. So I'm pretty sure the proposed change only affects new setups. Roy ___ 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] Git Tag comments
On 13/02/17 01:01, Roy Marples wrote: > 1) add an option to (or to not) export tags. The git default is not to, > I'm tempted to make this the fossil default as well. See *. This is wrong. Git has no such option. > 2) maintain a file of tags so we only export tags generated at the > fossil side, and even then only once. See *. > > 3) adjust fossil to store a comment for the tag. Guidance on how to do > this is welcome :) > > * Apparently git can sign tags with GPG. I've not tried it. This alters > the signature of the tag. I have no idea how fossil reacts here, but > will probably be OK as it can handle many tags whereas git just has the one. I'm currently leaning towards 3, even though it's the more complicated because it doesn't lose data. Comments on how to achieve this are welcome. Roy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Git Tag comments
Hi List So git fast-export only exports anointed tags - they usually have a comment. Fossil tags don't have comments. This is slightly problematic for a bridge. Because we add all tags to the fast-export file they will overwrite tags at the other end. As such, the git repos that sync to the git end of the bridge will get an error that the tag they just synced already exists. Then can do this `git pull --rebase --tags` and get a tag update record, and see their comment dropped. So I see three possible solutions: 1) add an option to (or to not) export tags. The git default is not to, I'm tempted to make this the fossil default as well. See *. 2) maintain a file of tags so we only export tags generated at the fossil side, and even then only once. See *. 3) adjust fossil to store a comment for the tag. Guidance on how to do this is welcome :) * Apparently git can sign tags with GPG. I've not tried it. This alters the signature of the tag. I have no idea how fossil reacts here, but will probably be OK as it can handle many tags whereas git just has the one. I think that we need to implement 1 anyway. Then it's just a matter of deciding between 2 and 3. Comments welcome. Roy ___ 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] Git Tag comments
On 13/02/17 01:23, Roy Marples wrote: > On 13/02/17 01:01, Roy Marples wrote: >> 1) add an option to (or to not) export tags. The git default is not to, >> I'm tempted to make this the fossil default as well. See *. > > This is wrong. Git has no such option. > >> 2) maintain a file of tags so we only export tags generated at the >> fossil side, and even then only once. See *. >> >> 3) adjust fossil to store a comment for the tag. Guidance on how to do >> this is welcome :) >> >> * Apparently git can sign tags with GPG. I've not tried it. This alters >> the signature of the tag. I have no idea how fossil reacts here, but >> will probably be OK as it can handle many tags whereas git just has the one. > > I'm currently leaning towards 3, even though it's the more complicated > because it doesn't lose data. 3 has now been implemented in the roy-export branch. Turned out to be quite easy. A database rebuild is required though as an extra field has been added to the tagxref table. This means that my git <-> fossil bridge is now fully working - for my normal work flow at least. Summary of changes from trunk: * tag committer is exported * import user matching works via contact info * exported branch and tag names are no longer mangled * no more silent renaming of master vs trunk [1] * tag importing actually works for git * tag comments are imported and exported [2] Testing now welcome. Roy [1] There is still the issue of the silent trunk in fossil. I don't know if what I've done here is correct. Artifacts look like a bug, but explicit renaming of master -> trunk works around it. [2] You can also see the comments in the timeline, which is nice. But there currently isn't a UI in fossil itself to enter a tag comment. ___ 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] Git Tag comments
On 13/02/2017 06:47, Artur Shepilko wrote:
>> * no more silent renaming of master vs trunk [1]
>
> "fossil import --rename-trunk" already allows a choice for a Fossil
> branch name to receive Git's "master" branch.
> A bug was missed in src/import.c:~567 if( fossil_strcmp(z,
> "master")==0 ) z = "trunk";
>
> In src/import.c this option is stored in gimport.zTrunkName, so for
> the purposes it should be used there instead of the ggit.zMasterName
> introduced.
> It can be something to this effect:
> if( fossil_strcmp(z, "master")==0 ){
> gg.zBranch = fossil_strdup(gimport.zTrunkName);
> }else{
> gg.zBranch = fossil_strdup(z);
> }
>
> Makes sense?
No, not really.
--rename-master renames master
--rename-trunk renames trunk
We should strive to keep the command line UI sane.
In both fossil and git, it's possible to have both master and trunk
branches.
>> * tag comments are imported and exported [2]
>
> ?? How does one enter a tag comment from the Fossil command line or
> this is an import/export only feature?
Currently this is only import/export changes.
I might be able to modify the command line to accept a comment for a tag.
> Fossil tags are kinda dated
> "lightweight" Git tags, yet unlike Git multiple commits can have the
> same tag. Does this suggest also same tags but also with different
> comments?
The git-fast-import format does not support "lightweight" tags, only
anointed ones. However, the way I've implemented it in Fossil should
allow multiple tags to have different comments. I have not yet addressed
the issue of git itself not accepting matching tags for different commits.
Roy
___
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] Git Tag comments
On 13/02/2017 09:49, Roy Marples wrote: >>> * tag comments are imported and exported [2] >> >> ?? How does one enter a tag comment from the Fossil command line or >> this is an import/export only feature? fossil tag add --comment "A tag test comment" tagtest current now works. Roy ___ 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] Git Tag comments
On 13/02/2017 10:42, Jan Nijtmans wrote: > 2017-02-13 4:50 GMT+01:00 Roy Marples: >> 3 has now been implemented in the roy-export branch. >> Turned out to be quite easy. A database rebuild is required though as an >> extra field has been added to the tagxref table. > > Thanks, Roy! I looked at your implementation: cards have to > be in alphabetical order, so a "C" tag after a "T" tag will simply > not work. Fixed! Thanks for pointing that out. > But ... tag are allowed to have a "value", which is > currently not used in fossil. This would be more logical. > Advantage: no schema change is necessary. Is the value displayed in the timeline? I'm also unsure about overloading the meaning of tag value . the ui indicates it can be set via the command line so could someone be using it for something else to store in fossil? Roy ___ 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] Git Tag comments
On 13/02/2017 11:12, Jan Nijtmans wrote: > 2017-02-13 12:09 GMT+01:00 Roy Marples: >> Is the value displayed in the timeline? > Yes >> I'm also unsure about overloading the meaning of tag value . the ui >> indicates it can be set via the command line so could someone be using >> it for something else to store in fossil? > > For some tags, like "color" or "branch" the tag value has > meaning in Fossil. But for "sym-" tags, the value currently > is not used for anything (other than displaying it in the timeline). > > Does that answer your question? Yes it does, thanks. I still think using a Comment card is a cleaner design though. Roy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil export to git broken for duplicate tags
Hi List! I have a few repos which I sync to git. However, one of them I noticed is no longer syncing tags. The fossil repo is here: https://roy.marples.name/projects/dhcpcd Using fossil-1.37 fossil export --git dhcpcd.fossil > dhcpcd.export git init dhcpcd-git cd dhcpcd-git git fast-import <../dhcpcd.export error: multiple updates for ref 'refs/tags/dhcpcd_6_11_3' not allowed. git tag # No tags are shown, but it did import a few of them according to stats The clue is in the error. Now, fossil probably doesn't know which tag to use (first? last?) which might be the case, but in that instance fossil should error out, or at least print a warning during the export phase. Roy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Branch and Tag names in export
Hi List! In fossil I have this: branch-1.7, tag-1.2 But when I export I get this: branch_1_7, tag_1_2 Why is the name mangled like so? Surely the original names should be preserved. Roy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] fossil exports unattributed tags
Exporting tags using fossil-1.37 I see this in the resultant import: tagged by whereas is should be tagged by Roy Marples <r...@marples.name> ___ 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] fossil exports unattributed tags
On 09/02/2017 14:39, Roy Marples wrote:
> Exporting tags using fossil-1.37 I see this in the resultant import:
>
> tagged by
>
> whereas is should be
>
> tagged by Roy Marples <r...@marples.name>
Patch attached to fix this.
Roy
Export tag comitter.
--- src/export.c.orig 2017-02-09 16:43:29.644172429 +
+++ src/export.c
@@ -632,7 +632,8 @@ void export_cmd(void){
/* Output tags */
db_prepare(,
- "SELECT tagname, rid, strftime('%%s',mtime)"
+ "SELECT tagname, rid, strftime('%%s',mtime),"
+ " (SELECT coalesce(euser, user) FROM event WHERE objid=rid)"
" FROM tagxref JOIN tag USING(tagid)"
" WHERE tagtype=1 AND tagname GLOB 'sym-*'"
);
@@ -642,6 +643,7 @@ void export_cmd(void){
int rid = db_column_int(, 1);
char *zMark = mark_name_from_rid(rid, _mark);
const char *zSecSince1970 = db_column_text(, 2);
+const char *zUser = db_column_text(, 3);
int i;
if( rid==0 || !bag_find(, rid) ) continue;
zTagname += 4;
@@ -652,7 +654,9 @@ void export_cmd(void){
printf("tag %s\n", zEncoded);
printf("from %s\n", zMark);
free(zMark);
-printf("tagger %s +\n", zSecSince1970);
+printf("tagger");
+print_person(zUser);
+printf(" %s +\n", zSecSince1970);
printf("data 0\n");
fossil_free(zEncoded);
}
___
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] fossil export handling of trunk differs from import
On 09/02/2017 21:42, Roy Marples wrote: > When importing a git fast import file, the master branch is silently > changed to trunk, to match the fossil default. > However, when exported back out the reverse conversion does not apply. > > This is not good, because fossil is effectively re-writing history. > But what is worse is that the export does not match the import I'm > striving to get out pretty much exactly what I put in. The silent branch renaming is problematic, but solvable. Both fossil and git work fine without a master or trunk branch. It is just a question of changing the defaults. I propose the following: Without any options, both import and export preserve the original naming scheme. However, we use the provided options to handle preference. fossil import --rename-master trunk fossil export --rename-trunk master This would allow a bi-directional bridge where the default trunk name is respected at both ends. It would also allow the crazy situation where you have both trunk AND master branches. Commentary on this default changing idea welcome. Roy ___ 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] [PROPOSED FEATURE] Fossil commands output sent through a pager
On 26/03/2017 22:19, Joerg Sonnenberger wrote: On Sun, Mar 26, 2017 at 07:49:30PM +0200, Tomasz Konojacki wrote: For someone with a different background, there is *nothing* nice about fossil dumping thousands of lines to the terminal. In fact, I think it scares off newbies who only used git before. I quite disagree. Terminal output is C friendly. Pager output tends to disappear with the pager. That's a real world UX issue I have with the git default settings. Pager output disappearing with the pager (I assume when asking the pager to exit) is an issue with the pager. As Fossil is a single binary to do everything approach, I'm sure that a Fossil pager would not suffer this defect. Yes, terminals have scroll bars and can page up, but that's the wrong approach as well. When viewing a diff I want to start at the top and scroll down, not start at the bottom and scroll up, hence a pager makes perfect sense. Roy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
