git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 0/2] apply.c: a fix and an enhancement

From
A Large Angry SCM <gitzilla@gmail.com>
Date
Jul 22, 2005, 20:29 UTC
Message-ID
<42E1571B.8070108@gmail.com>
In-Reply-To
<7vsly6vd2b.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
Show 25 quoted lines
> Ryan Anderson <ryan@michonline.com> 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.

Previous: Ryan AndersonNext: Linus Torvalds
Message 5 of 16 in “apply.c: a fix and an enhancement”
  1. 0/2 apply.c: a fix and an enhancementJunio C Hamano, Jul 22, 2005
  2. Ryan AndersonJul 22, 2005
  3. Junio C HamanoJul 22, 2005
  4. Ryan AndersonJul 22, 2005
  5. A Large Angry SCMJul 22, 2005
  6. Linus TorvaldsJul 22, 2005
  7. Junio C HamanoJul 22, 2005
  8. Linus TorvaldsJul 22, 2005
  9. Santi BéjarJul 22, 2005
  10. Junio C HamanoJul 22, 2005
  11. Linus TorvaldsJul 22, 2005
  12. Petr BaudisJul 22, 2005
  13. Junio C HamanoJul 23, 2005
  14. Petr BaudisJul 22, 2005
  15. Linus TorvaldsJul 22, 2005
  16. Petr BaudisJul 22, 2005

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.