I think you are wrong with your ideas. Committing not working code is not a bad 
practice at all. Commit often, commit always. I am committing not working code 
all the time and it works great for me. :)
  
I am only trying to keep the trunk branch working (notice: only "trying"). 
Create new branch for every feature you want to experiment and when it is 
ready, simply merge it with the trunk.

You can see how it look in practice, on one of my repositories: 
http://fresh.flatassembler.net/fossil/repo/fresh/timeline

You can see for example: 2014-06-14:    

[42504ecb33] Leaf: Partially fixed (compiles, but not working properly) 
TScrollWindow and TFreshEdit. (user: johnfound, tags: FreshLibGUI) 


On Sat, 14 Jun 2014 17:15:12 +0300
<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.


-- 
asm32.info <johnfo...@asm32.info>
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to