Hi all,

I'm wondering how best to go about this problem.  I've got two
separate git repositories -- one is a portable version which I'll call
"portable", the other is part of a BSD project, which I'll call "bsd".
 Both repositories have the same set of *conceptual* files in them,
it's just that the portable repository has additional files which are
not found in the bsd repository.  It should be noted that the bsd
repository is an automatically managed cvsexport clone of a CVS
repository -- but I don't think this matters here, as we're just
talking about two git repositories.

The "workflow" if you can call it that, is commits happen in the bsd
repository and are then put in the portable repo.  At the moment, I am
using git grafts to do this.  The important point to remember here is
the two repositories DO NOT have any common history to them -- it's
just that where the files are the same in both the bsd and portable
repository I can see and hence tell git, where to graft the two master
branches from each repository and for me to merge bsd:master ->

However, I am wondering how best to handle this situation.  It's
pretty convoluted -- not to mention the fact that git grafts are never
permanent.  What I'd like is for some "safe" way of setting up an
initial git graft which tied the two master branches between bsd and
portable to reflect changes on bsd:master not on portable:master and
then for me to treat those two branches as though they shared common
history so that I can merge one to the other.  Unfortunately, what I'm
doing at the moment is each time changes happen to bsd:master, I'm
having to reset the git graft each time; and since that operation is a
local one, it makes things rather awkward in a shared repository
situation as I am the sole person who can perform these merges.

I'm guessing I could rebase at some point and push those changes out?
I'm just wondering how other people handle this situation or if it's
just unique to me?


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to