SQLite Forum

Maybe fossil problem ?
Login

Maybe fossil problem ?

(1) By Domingo (mingodad) on 2021-03-24 09:10:57 [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?

(4) By Domingo (mingodad) on 2021-03-24 14:07:15 in reply to 2 [link] [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.

(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.