Junio C Hamano wrote:
Ryan Anderson <[EMAIL PROTECTED]> writes:
On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote:
Now if we had a mechanism to graft a later history which starts
at 2.6.12-rc2 on top of this earlier history leading up to
it,... ;-)
We do - it's not even very hard, we just end up with 2 commits for every
change/merge that's unique to git, until we get to the current head:
Aren't you essentially rewriting the history after 2.6.12-rc2?.
I suspect that would invalidate the current linux-2.6 history
people have been basing their work on since 2.6.12-rc2, which is
unacceptable. That is not what I meant by "grafting".
What I meant was to give a hint to the core that says "this
2.6.12-rc2 commit in the current linux-2.6.git tree is recorded
as not having a parent, but please consider it the same as this
other 2.6.12-rc2 commit in the 2.4.0->2.6.12-rc2 history when
traversing the commit ancestry chain".
If git-rev-list is taught about that, then you will see "git
log" going across 2.6.12-rc2. If git-merge-base is taught about
that, it will be able to find a merge base to merge a line of
development that is forked from say 2.6.11 to the current tip of
linux-2.6 tree.
I think that "rewriting history" in this case may be the better option
in _this_ case. But only because the tools are new and the users are
understanding. :-)
To do it without the history rewrite, create an alternate_history
directory under .git with it's own objects tree. And populate that
object tree with "alternative" content for the objects in the normal
trees. Then teach the things the lookup/read objects to look there first
and to _not_ care about invalid SHAs. Of course, if you do this, you
will never be able to trust your repository.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
