On Mon, Mar 25, 2013 at 01:04:53PM -0700, Peter Pavlovich wrote: [...] > - It appears your comments for the "can git support 'sparse' workspaces" > question was lost. All that you posted was "Yes and No. Git supports". It > appears that the remainder of your comments were cut off.
Sorry. I've decided to first deal with other chunks of your message and forgot to return to this one. "Yes and no" means that Git does not support directly what you described: there's no way to check out a single directory out of a tip commit of a branch, nor are there any ways to make Git not check out something. On the other hand, I reckon that instead of trying to hide parts of a repository, a better approach might be going modular instead: Git supports the so-called "submodules". A submodule is a (completely) independent repository, which is referenced by another repository (works pretty much like Subversion "externals" if you're familiar). That way, you could structure your repository so that there is a relatively small "core" repository which references a number of "satellite" repositories containing supporting files. A given commit in the referring repository always links to exact specific commits of its submodules, so any state might be reconstructed precisely. Another thing which might help you while not addressing the specific problem are "sparse clones" -- the only problem is that they are "depth-sparse", not "width-spare": you can tell Git to only fetch a tip commit (or N commits) of a specified branch to conserve bandwidth and disk space. The resulting repository will obviously be "lame" compared to a full-fledged clone, but that would work OK for certain workflows. Git also supports several bizzare approaches to "faking" history records, namely, git-replace [2] and grafting [3]. Replacing allows you to have a shorter/smaller version of a repository while at the same time having a huge record of past history available for those who need it. I have no personal experience with these tools so will stop handwaving about them at this point. > - For the last question, how then would one "update" a branch of a > repository to include changes in the "main" branch. For example, let's > assume I have a brand new git repo. I add some files to it, let's say, > representing version "A" of my application. I now "branch" this repo in > order to work on version "B" of my repo. I want the "B" branch to be an > integration branch into which two separate teams will "dump" their > eventual > changes for two headlines" Each of these two teams then create separate > branches stemming from "B", call them "B1" and "B2" representing work on > these two independent headlines. Team 1 reaches a milestone and wants to > "push" their completed code into "B" and begin work on the next headline. > They would like to do something in Git to synchronize their "B1" branch > with the contents of "B" so that the two branches would, upon completion > of > that "something", have identical contents. Assuming that is possible and > it > is now completed, team 2 would like to "pull" the current state of "B" > into > their own branch "B1", merging that content with what they have done in > "B2" so that, when they are done, B2 would have all of the changes that B1 > pushed up to B + any additional, interim changes they have made thus far > in > B2 prior to this action. When they are done with their headline, they > would > like to sync "B2" with "B" so that "B" would then have all of their > changes > too. Is there any way to accomplish this sort of thing in Git? How would > one coordinate the work of multiple teams working on different headlines > all of which eventually have to be "merged" into one codebase? Git has three devices to exchange commits between branches: * Merging. Different SCMs put somwehat different semantics to this. Since Git always operate on complete repository snapshots, when you merge branch B into A, the result (a new commit on A) means A now contains changes on both A and B. Since a merge commit records all of its parents (Git supports "octopus merges" so there might be more than two parents), it's relatively straighforward to do "reintegration" merges: for instance, if we consider our merger of B and A, the next attempt to merge B into A, after both branches were updated, will do a three-way merge, using the tip commits of both branches and their "merge base" commit -- the result of the last merge. So merging is the most popular way of continuous exchange of commits between branches. * Cherry-picking. This is taking commits from one branch and applying them onto another as if they were just patches. This does not record any ancestry information but Git is smart enough to detect already applied changes, so when you cherry-pick a commit from B to A and later merge B to A, there's a good chance there will not be a conflict due to (apparent) double application of that cherry-picked commit to the same receiving branch. This feature is mostly used for backporting of critical fixes from development code to "stable" branches. * Rebasing. This is a complicated beast which I feel I have not enought energy at the moment to properly and succintly describe (better read a book on the subject, like the classic "Pro Git" by Scott Chacon). Basically, rebasing allows you to develop something on a branch, then fetch its updated "upstream" version from the shared repository and transplant your changes so that they appear on top of the *updated* branch. Thus it allows you to "forward-port" your local changes. So what tool among those (or a combination of them) to use, depends on the use case. From your description, it appears to me that merging should be all that's required. There are numerous possible branching workflows possible with Git, but I'd recommend reading a classic essay presenting one of them [1]. 1. http://nvie.com/posts/a-successful-git-branching-model/ 2. http://git-scm.com/2010/03/17/replace.html 3. https://git.wiki.kernel.org/index.php/GraftPoint -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
