Johannes Schindelin writes:

quoted text
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html