[removed linux-kernel list from Cc] Chase Venters <chase.venters@xxxxxxxxxxxx> 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 - 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
