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  and grafting . 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
> 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
> that "something", have identical contents. Assuming that is possible and
> is now completed, team 2 would like to "pull" the current state of "B"
> 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
> B2 prior to this action. When they are done with their headline, they
> like to sync "B2" with "B" so that "B" would then have all of their
> 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"
* 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 .
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
For more options, visit https://groups.google.com/groups/opt_out.