Hi,

Earlier this month I asked how best to handle two branches without a
common ancestor to sync changes from one branch to another.  Initially
I did this via the grafts mechanism, but this wasn't a "shared"
solution, in that the graft was local to my checkout of the repository
and no one else's.

I read on StackOverflow that git-replace can be used instead.  Having read this:

http://stackoverflow.com/questions/3810348/setting-git-parent-pointer-to-a-different-parent

I followed the instructions to use git-replace.  Have successfully
done that, I was then able to merge the two branches which didn't have
a common ancestor and have the correct commits on the branch I was
hoping for.  AFAIAC, this worked fine.

But now I have some questions:

1.  I thought the replace data in .git/refs/replace was published when
I did "git push" so that others could use this information as a
base-point, yet it seems not to be the case.  How do I publish this?
2.  If I do publish it, are there any caveats with that?  i.e.,
because the replace data will likely point to a repo which in my
working checkout I added with "git-remote", is that going to be a
problem?  I assume I can instruct people who care, to "git remote add
foo ...." and then treat master and foo/master as intended?  i.e.,
foo/master will see commits on it over time which "master" won't have,
so "git checkout master && git merge foo/master" can always happen?
3.  If it is possible to publish this replace data, is there anything
which needs to happen in .git/config either on the bare repo or local
checkouts?

What I'm aiming for now, in publishing this merge, is that if I can
publish the replace data, that people besides me, can clone the repo,
and the remote repo in place, and merge the branches as outlined in
question 2.   What I also am unsure of is whether or not I have to
keep updating the replace refs each time I merge the branch?

TIA!

David
--
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