Re: Question about your git habits

[Junio C Hamano <gitster@pobox.com>]

Chase Venters <chase.venters@clientec.com> 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.