Maybe fossil problem ?
(1) By Domingo (mingodad) on 2021-03-24 09:10:57 [link] [source]
I use to follow the sqlite3 development almost daily (updating my cloned repository) and today I'm getting a conflict in a file that I don't have made any custom changes src/epr.c (see below) and I'm reporting it here just in case it can give a clue in how (if possible/convenient) improve fossil (if at all because it seems strange that it generates a conflict following the main repository). ------ ExprList *sqlite3ExprListAppend( Parse *pParse, /* Parsing context */ ExprList *pList, /* List to which to append. Might be NULL */ Expr *pExpr /* Expression to be appended. Might be NULL */ ){ struct ExprList_item *pItem; if( pList==0 ){ <<<<<<< BEGIN MERGE CONFLICT: local copy shown first <<<<<<<<<<<<<<< pList = sqlite3DbMallocRawNN(db, sizeof(ExprList) ); if( pList==0 ){ goto no_mem; } pList->nExpr = 0; }else if( (pList->nExpr & (pList->nExpr-1))==0 ){ ExprList *pNew; pNew = sqlite3DbRealloc(db, pList, sizeof(*pList)+(2*(sqlite3_int64)pList->nExpr-1)*sizeof(pList->a[0])); if( pNew==0 ){ goto no_mem; } pList = pNew; ||||||| COMMON ANCESTOR content follows |||||||||||||||||||||||||||| pList = sqlite3DbMallocRawNN(db, sizeof(ExprList) ); if( pList==0 ){ goto no_mem; } pList->nExpr = 0; }else if( (pList->nExpr & (pList->nExpr-1))==0 ){ ExprList *pNew; pNew = sqlite3DbRealloc(db, pList, sizeof(*pList)+(2*(sqlite3_int64)pList->nExpr-1)*sizeof(pList->a[0])); if( pNew==0 ){ goto no_mem; } pList = pNew; ======= MERGED IN content follows ================================== return sqlite3ExprListAppendNew(pParse->db,pExpr); } if( pList->nAlloc<pList->nExpr+1 ){ return sqlite3ExprListAppendGrow(pParse->db,pList,pExpr); >>>>>>> END MERGE CONFLICT >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> } pItem = &pList->a[pList->nExpr++]; *pItem = zeroItem; pItem->pExpr = pExpr; return pList; <<<<<<< BEGIN MERGE CONFLICT: local copy shown first <<<<<<<<<<<<<<< no_mem: /* Avoid leaking memory if malloc has failed. */ sqlite3ExprDelete(db, pExpr); sqlite3ExprListDelete(db, pList); return 0; ||||||| COMMON ANCESTOR content follows |||||||||||||||||||||||||||| no_mem: /* Avoid leaking memory if malloc has failed. */ sqlite3ExprDelete(db, pExpr); sqlite3ExprListDelete(db, pList); return 0; ======= MERGED IN content follows ================================== >>>>>>> END MERGE CONFLICT >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> } ------
(2) By Richard Hipp (drh) on 2021-03-24 11:07:03 in reply to 1 [link] [source]
How did you get this conflict? What steps did you follow to produce it?
(3) By anonymous on 2021-03-24 11:31:16 in reply to 1 [link] [source]
I've had similar conflicts when, for example, I open/save a file in an editor that automatically trims end-of-line spaces.
(4) By Domingo (mingodad) on 2021-03-24 14:07:15 in reply to 2 [source]
I think that maybe I had done something like described by "(3) By anonymous on 2021-03-24 11:31:16", other than that the usual daily "fossil update". And maybe would be nice to have the end-of-line spaces trimmed by default.
(5) By Stephan Beal (stephan) on 2021-03-24 15:12:33 in reply to 4 [link] [source]
And maybe would be nice to have the end-of-line spaces trimmed by default.
Fossil necessarily saves exactly what it is given, with the unfortunate obligatory exception that it can optionally replace the newlines to a consistent style.
Stripping trailing spaces would break certain files, possibly in subtle ways. e.g. at least one flavor of markdown uses backslash-blank-blank to force a line break within a paragraph.