Re: Question about your git habits

[Jakub Narebski <jnareb@gmail.com>]

[removed linux-kernel list from Cc]

Chase Venters <chase.venters@clientec.com> writes:

> 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?

Alternate solution is to use multiple working trees (multiple working
directories) with single repository, although it is still a bit
fragile; you should take care to not checkout same branch multiple
times. IIRC when discussing ".git" as a file representing symlink,
there were some discussion on how to improve multiple-workspaces
workflow.
 
> 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?

I personally prefer this workflow, but I do not work as a main
contributor nor maintainer of large project.

As to intermediate commits: if you feel the need to interrupt your
work which is not quite ready for final commit, you can either use
"git stash" command, or commit it as WIP commit, then when going back
just "git commit --amend" it.

Moreover, when working on some larger topic, which needs to be split
into individual commits for beter history clarity, and for better
bisectability, you usually rewrite history before submitting
(publishing) your changes. You usually have to reorder commits (for
example moving improvements to infrastructure before commits
introducing new feature), split commits (separating just noticed
bugfix from a feature commit), squash commits (joining feature commit
and its bugfix) etc. You can use "git rebase --interactive" for that,
or one of Quilt-like patch management interfaces for git: StGit (which
I personally use) or Guilt (idea based on mq: Mercurial queues
extension).

[...]

> It seems to me that having multiple working trees (effectively, cloning 
> the "master" repository every time I need to make anything but a trivial 
> change) would be most effective under git as well as it doesn't require 
> creating messy, intermediate commits in the first place (but allows for them 
> if they are used). But I wonder how that approach would scale with a project 
> whose git repo weighed hundreds of megs or more. (With a centralized rcs, of 
> course, you don't have to lug around a copy of the whole project history in 
> each working tree.)

You can always clone using --shared option to set-up alternates; this
way only new objects (new commits) would be stored in the clone. This
of course need for clone and source to be on the same filesystem.

By default git-clone on local filesystem uses hardlinks, so it also
should not be so hard on disk space.

-- 
Jakub Narebski
Poland
ShadeHawk on #git