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

Re: [PATCH v3] user-manual: add advanced topic "bisecting merges"

From
Junio C Hamano <gitster@pobox.com>
Date
Nov 10, 2007, 10:36 UTC
Message-ID
<7vsl3emlpc.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<119468808499-git-send-email-prohaska@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> ...
> +A solution is to linearize the history by rebasing the lower
> +branch on top of the upper, instead of merging. There were no

Hmm. When I wrote it, I did not mean this as a "solution", but as an illustration of how a merge heavy history and a linear history have impact on bisectability. So it is more like...

    On the other hand, if you did not merge at C but rebased the
    history between Z to B on top of A, you would have get this
    linear history [illustration here].  Bisecting between Z and
    D* would hit a single culprit commit Y* instead.  This tends
    to be easier to understand why it is broken.

For this reason, many experienced git users, even when they are working on an otherwise merge-heavy project, keep the histories linear by rebasing their work on top of public upstreams before publishing (when able). An extreme example: merges from a few top-level lieutenants to Linus in the kernel, e.g. David Miller, are known to _almost always_ fast-forward for Linus.

IOW, the description is to mildly encourage private rebasing to keep the job of later bisecting (for potentially others) easier. I realize I originally wrote as if C (merge) was made by the same person as the person who ends up bisecting, but that is not necessarily the case. Keeping the history without needless merges tend to make _other_ people's lives simpler.

And after encouraging the private rebasing, I would continue like...

    But if you already made a merge C instead of rebasing, all
    is not lost.  In the illustrated case, you can easily rebase
    one parent branch on top of the other after the fact, just
    to understand the history and to make the history more
    easily bisectable.  Even though the published history should
    not be rewound without consent with others in the project,
    nobody gets hurt if you rebased to create alternate history
    privately.  After understanding the breakage and coming up
    with a fix on top of D*, you can discard that rebased
    history, and apply the same fix on top of D, as D* and D
    should have the identical trees.
Previous: Steffen ProhaskaNext: Steffen Prohaska
Message 16 of 30 in “user-manual: add advanced topic "bisecting merges"”
  1. user-manual: add advanced topic "bisecting merges"Steffen Prohaska, Nov 4, 2007
  2. Ralf WildenhuesNov 4, 2007
  3. user-manual: add advanced topic "bisecting merges"Steffen Prohaska, Nov 7, 2007
  4. Benoit SigoureNov 7, 2007
  5. J. Bruce FieldsNov 7, 2007
  6. Steffen ProhaskaNov 8, 2007
  7. Johannes SixtNov 8, 2007
  8. Steffen ProhaskaNov 8, 2007
  9. Johannes SixtNov 8, 2007
  10. Andreas EricssonNov 8, 2007
  11. Johannes SixtNov 8, 2007
  12. Steffen ProhaskaNov 8, 2007
  13. Johannes SixtNov 8, 2007
  14. Steffen ProhaskaNov 8, 2007
  15. user-manual: add advanced topic "bisecting merges"Steffen Prohaska, Nov 10, 2007
  16. Junio C HamanoNov 10, 2007
  17. Steffen ProhaskaNov 10, 2007
  18. user-manual: Add section "Why bisecting merge commits can be harder ..."Steffen Prohaska, Nov 10, 2007
  19. Linus TorvaldsNov 10, 2007
  20. Junio C HamanoNov 10, 2007
  21. Steffen ProhaskaNov 10, 2007
  22. J. Bruce FieldsNov 18, 2007
  23. Steffen ProhaskaNov 18, 2007
  24. J. Bruce FieldsNov 18, 2007
  25. Andreas EricssonNov 8, 2007
  26. Benoit SigoureNov 8, 2007
  27. Steffen ProhaskaNov 8, 2007
  28. Johannes SchindelinNov 8, 2007
  29. Brian GernhardtNov 8, 2007
  30. Benoit SIGOURENov 4, 2007

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.