On Aug 3, 2015, at 1:31 PM, Andy Goth <[email protected]> wrote:
>
> Many times I've created files, modified existing files to reference
> them, tested, and committed, only to later discover I forgot to add the
> newly created files to the repository.
Yup, been there. :)
> After making this mistake, I know I'm supposed to move the bad commit to
> a hidden branch
Who supposes this, and why do you take their opinion as normative?
I thought I saw reference on this list to a way to lop off the most-recent
checkin on a particular branch, but I couldn’t figure out how the last time I
tried. Is this the mechanism?
> Usually I don't bother, especially if
> there have been check-ins since the error was committed.
Wouldn’t a better solution to that problem be a continuous integration system,
so you get an email shortly after committing a change that breaks the build?
Then your risk window shrinks to the CI rebuild time.
> Maybe even merge the lists, prefixing
> each line with EXTRA or MISSING or NON_UTF8 or CRLF.
I rarely run into this one, since I normally just say “all” when asked if I
really meant to do that, since I usually did mean to. Then I go and hack on
the relevant *-glob setting.
> Oops, Fossil refers to CRLF as CRNL... that's always confused me.
Ditto. Why fight ASCII on naming here?
> does Fossil squawk about files using CR alone
> or LFCR?
Yes:
$ file foo.c # inverse-DOS line endings (LFCR)
foo.c: ASCII C program text, with CRLF, CR, LF line terminators
$ file bar.c # Mac OS classic line endings (CR)
bar.c: ASCII C program text, with CR line terminators
$ f ci
./foo.c contains mixed line endings. Use --no-warnings or the
"crnl-glob” setting to disable this warning.
Commit anyhow (a=all/c=convert/y/N)? n
./bar.c contains CR line endings. Use --no-warnings or the
"crnl-glob" setting to disable this warning.
Commit anyhow (a=all/c=convert/y/N)? n
$
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
