Hello, On 14 June 2014 16:15, <to...@acm.org> wrote: > > 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?
This does not answer your question - since you already mentioned it yourself, but I'd simply choose a branch, where the timeline actually shows the truth of what happens/happened during development, even for potential dead ends. Perhaps private branches would work for you (http://www.fossil-scm.org/index.html/doc/tip/www/private.wiki) although I have no experience with them. Michai _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
