Chase Venters <chase.venters@xxxxxxxxxxxx> writes: [jc: kernel-list removed from CC: as this does not have anything to do with them] > My question is: If you're working on multiple things at once, > do you tend to clone the entire repository repeatedly into a > series of separate working directories and do your work there, > then pull that work (possibly comprising a series of > "temporary" commits) back into a separate local master > respository with --squash, either into "master" or into a > branch containing the new feature? > > Or perhaps you create a temporary topical branch for each > thing you are working on, and commit arbitrary changes then > checkout another branch when you need to change gears, finally > --squashing the intermediate commits when a particular piece > of work is done? It is a matter of taste, but in any case, you should not have to squash that often. If you find you are always squashing because you work on one thing and then switch to another thing before you are done with the former, something is wrong. Clarification: I am not saying squashing is wrong. I am just saying you should not have to. If you want to park what you were working on before switching to do something else, you can (and probably should) commit and it is a very valid thing to do (an alternative is "git stash"). When resuming, if that parked commit was half-baked and something you do not want to go back to later, then the next commit (be it another commit that merely "parks" before getting distracted to do something else, or a commit that finally gets everything "finito") can be made with "commit --amend". That way, your sequences of commits will consist of only logically separate units, without half-baked ones you had to create only because you switched branches. Some people prefer to use multiple simultanous work trees. You certainly can use "clone" to achieve this. And local clone is very cheap as it shares the object database from the origin by default. Many people prefer to use topic branches, and working in a single repository with multiple branches and switching branches without ever cd'ing around is certainly a possible and very valid way to work. As long as your build infrastructure is sane (e.g. your project does not have a central header file that any little subsystem change needs to modify and included by everybody, which tends to screw up make quite badly), switching branches would not incur too much recompilation either and it obviously will save disk space not having to leave multiple checkout around. You can also work with a single repository, multiple branches and have multiple simultaneous work trees attached to that single repository, by using contrib/workdir/git-new-workdir script. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
