I have a goal in my build system that says "commit". That goal tries to do a full build. If it succeeds, it tags my commit with "compiles". If it doesn't succeed it won't commit code and flips me off with an error.
Now I have a choice: I can commit anyway with a manual invocation of fossil (for which there are a billion valid reasons), I can branch-on-commit the same way, or I can fix whatever doesn't compile and hit up the commit target again. That way I have a myriad of broken commits, true, but the ones that at least build are flagged as such. On 14 June 2014 22:15, <to...@acm.org> wrote: > Hi all, > > It seems to me that commits are best (from a logical point of view) when > they refer to completed work, not for work-in-progress (WIP). Besides, > it’s not nice to see a timeline filled with incomplete non-working code. > For example, I create a new library code file that is under initial > development, but it may take many days/weeks to bring out the initial > version, which will become the first commit for this file. After that, > each completed/tested update (bug fixes, new features, etc.) will become > another commit. But, how do I save the WIP file in the repo in a > ‘temporary’ state so that it doesn’t keep track of all incomplete work in > the history. > > You could say, do not add it until it’s completed. Problem 1: Clean would > kill it, Problem 2: Working on multiple computers, taking changes along to > continue work in other location. > > Another possible solution is to make a new branch for each new file that > is WIP but that still doesn’t seem the best way, let alone after a while > the repo will be filled with a whole bunch of temp branches. And what if > the new code depends on many of the trunk files? The ‘trunk’ code could be > making significant changes (perhaps, some incompatible ones), and the > ‘temporary’ branch will have the version of the time the new files started, > unless every time ‘trunk’ changes everything is merged into the branch. > Besides, making a branch, merging, ... also has the same problem of > ‘polluting’ the timeline with unnecessary history. > > I would like to somehow temporarily store the file in the repo (like with > a STASH) but in a way that it will stay there even if I close the repo. > > Any ideas or suggestions how to deal with this issue? > > TIA. > > _______________________________________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > -- "Perhaps people don't believe this, but throughout all of the discussions of entering China our focus has really been what's best for the Chinese people. It's not been about our revenue or profit or whatnot." --Sergey Brin, demonstrating the emptiness of the "don't be evil" mantra.
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users