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
