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

Re: Avoiding broken Gitweb links and deleted objects

From
Junio C Hamano <gitster@pobox.com>
Date
May 10, 2013, 07:16 UTC
Message-ID
<7vvc6r4855.fsf@alter.siamese.dyndns.org>
In-Reply-To
<CACsJy8CopioiTrEDfuZK=n1DfJ8_chxV9dEObqpVfHHmJvzyqQ@mail.gmail.com>
Duy Nguyen <pclouds@gmail.com> writes:
Show 16 quoted lines
> On Fri, May 10, 2013 at 1:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> Johannes Sixt <j.sixt@viscovery.net> writes:
>> Imagine that a user runs "git rebase" on a history leading to commit
>> X to create an alternate, improved history that leads to commit Y.
>> What if we teach "git rebase" to record, perhaps by default, an
>> "ours" merge on top of Y that takes the tree state of Y but has X as
>> its second parent, and "git log" and its family to ignore such an
>> artificial "ours" merge that records a tree that is identical to one
>> of its parents, again perhaps by default?  "git log" works more or
>> less in such a way already, but we might want to teach other modes
>> like --full-history and --simplify-merges to ignore "ours" to hide
>> such an artificial merge by default, with an audit option to
>> unignore them.
>
> What about git-merge? Will it be fooled by these merges while looking
> for merge bases?

I thought it was obvious that we should ignore the side branches that were superseded this way, as by definition they did not contribute to the end result at all.

But there must be something huge that I missed; otherwise you wouldn't be asking such a question. It is already late and my brain is no longer quite working, so I cannot figure out what it is X-<.

Other things that I thought were obvious include format-patch (side branch and the capping merge did not exist), another rebase (just rebase the primary history ignoring the side branch and the capping merge, and then cap the result with another artificial merge), and shortlog (it should pretend that the side branch and the capping merge never happened).

Of course, there should be a way for any of these to take the side branch into account as if they are normal side branches as an option.

Previous: Duy NguyenNext: Duy Nguyen
Message 7 of 14 in “Avoiding broken Gitweb links and deleted objects”
  1. Matt McClureMay 8, 2013
  2. Matt McClureMay 9, 2013
  3. Johannes SixtMay 10, 2013
  4. Junio C HamanoMay 10, 2013
  5. Johannes SixtMay 10, 2013
  6. Duy NguyenMay 10, 2013
  7. Junio C HamanoMay 10, 2013
  8. Duy NguyenMay 10, 2013
  9. Junio C HamanoMay 10, 2013
  10. Matt McClureMay 22, 2013
  11. Junio C HamanoMay 22, 2013
  12. William SwansonMay 10, 2013
  13. Matt McClureMay 22, 2013
  14. William SwansonMay 22, 2013

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.