Johannes Schindelin writes: > Hi, > > On Mon, 5 Mar 2007, Bill Lear wrote: > >> No, I think you missed my point. There are two xyz.o's: >> >> One in .master/xyz.o, and one in .branchX/xyz.o. > > Why not put the two xyz.c's into .master/ and .branchX/ as well (surely, > the source files are small compared to the object files)? And just to make > sure, the Makefile, too (some Makefile targets depend on the timestamp of > this, too). > > And to make sure that if we're switching to a third branch, let's put the > files there, even when the side branch does not change them, otherwise > A->B->C->A might fail. > > And while at it, we could put the information about which branch this is > into the corresponding directories, too! Otherwise, we could rename the > directory by mistake, and the system would stop working. > > And the corresponding refs. They could be there, too. This all sounds a lot like git-clone's "alternate" code. Does a repository cloned with the -s or --references flag have some setting to make fetch and push work with the same remote repositories as the local origin, or do the remotes have to be manually propagated between the two local copies? If I git-fetch in the local clone, does it write the new objects to the local origin? My own work habits are very similar to Bill Lear's, but my projects' build times are small enough that it's less pain to rebuild half the project than to propagate changes recorded under $GIT_DIR between local branches. I have not found a git workflow that makes me entirely happy, but I suspect I just don't know the magic words. Michael Poole - 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