使用rebaseif工作流程是否可以使版本控制中的bisect受益? [英] Does a bisect in version control benefit from using a rebaseif workflow?

问题描述

仅当合并可以自动完成且没有冲突时，rebaseif扩展才可以在拉动时自动执行重新设置基础的过程. (如果存在手动解决的冲突，它不会重新设置基础，使您可以手动合并两个分支.)这可以简化和线性化开发人员在代码的不同部分中工作的历史记录，尽管任何重新设计的确会抛出异常消除了有关开发人员进行工作时的世界状况的一些信息.我倾向于同意类似 this 和 rebaseif扩展程序的作者开始觉得这是个坏主意..)

The rebaseif mercurial extension automates the process, when pulling, of doing a rebase only if the merge can be done automatically with no conflicts.  (If there are conflicts to resolve manually, it does not rebase, leaving you ready to do a manual merge of the two branches.)  This simplifies and linearizes the history when developers are working in different parts of the code, although any rebase does throw away some information about the state of the world when a developer was doing work. I tend to agree with arguments like this and this that in the general case, rebasing is not a good idea, but I find the rebase-if philosophy appealing for the non-conflict case. I’m on the fence about it, even though I understand that there are still risks of logic errors when changes happen in different parts of the code (and the author of rebaseif extension has come to feel it’s a bad idea..)

我最近经历了一个复杂而痛苦的二等分，我认为在我们的存储库中有大量的短分支合并是该二等分不履行其隐含O(lg n)承诺的主要原因.我发现自己需要多次运行"bisect --extend"，以扩大合并范围之外的范围，一次要经过几个变更集，本质上就是使bisect O(n).我还发现跟踪二等分的进行情况以及了解到目前为止获得的信息非常复杂，因为在查看存储库图时我无法跟踪分支.

I recently went through a complicated and painful bisect, and I think that having a large number of merges of short branches in our repository was the main reason the bisect did not live up to its implied O(lg n) promise.  I found myself needing to run "bisect --extend" many times, to stretch the range beyond the merge, going by a couple of changesets at a time, essentially making bisect O(n).  I also found it very complicated to keep track of how the bisect was going and to understand what information I'd gained so far, because I couldn't follow the branching when looking at graphs of the repository.

是否有更好的方法使用bisect(以及查看和了解修订历史记录)，或者如果我们在开发中使用了rebaseif，那么我的过程会更顺利.或者，您能否帮助我更具体地了解在非冲突情况下使用rebase可能会出什么问题:是否足以引起应避免的问题?

Are there better ways to use bisect (and to look at and understand the revision history) or am I right that the process would have been smoother if we had used rebaseif more in development. Alternately, can you help me understand more concretely what may go wrong using rebase in the non-conflict case: is it likely enough to cause problems that it should be avoided?

由于我认为rebaseif与更典型的git工作流程相匹配，因此我对它进行了更广泛的标记(不仅仅是Mercurial):git用户可能已经看到了陷阱.

I’m tagging this more generally (not just mercurial) since I think rebaseif matches a more typical git workflow: git users may have seen the gotchas.

推荐答案

我认为答案很简单:您必须在艰难的 bisects 或冒险的基础调整之间做出选择.

I think the answer is simple: you have to devide between hard bisects or risky rebasing.

或者，介于两者之间:仅在不太可能通过重设基准静默破坏事物的情况下才进行重设基准.如果重新建立基准只涉及几个变更集，这些变更集在语义上与要重新建立基础的变更相距甚远，通常可以安全地重新建立基准.

Or, something in between: only rebase if it is very unlikely that the rebase silently breaks things. If a rebase involves only a few changesets which additionally are semantically distant to the changes they are rebased on, it's usually safe to rebase.

在此示例中，无冲突的合并会破坏事情:

Here's an example, where a conflict-free merge breaks things:

假设两个分支从具有以下内容的文件开始:

Suppose two branches start from a file with this content:

def foo(a):
    # do
    # something
    # with a (an integer)

...

foo(4)

在分支A中，将其更改为:

In branch A, this is changed to:

def foo(a):
    # now this function is 10 times faster, but only work with positive integers
    assert a > 0
    # do
    # something with
    # with a

...

foo(4)

在分支B中，将其更改为:

In branch B, it is changed to:

def foo(a):
    # do
    # something
    # with a (an integer)

...

foo(4)

...

foo(-1) # now we have a use case where we need to call foo with -1

在语义上，两个编辑彼此冲突.但是，Mercurial可以愉快地合并它们而不会发生冲突(在两种情况下，当重新定基或进行常规合并时):

Semantically, both edits conflict with each other. However, Mercurial happily merges them without conflicts (in both cases, when rebasing or when doing a regular merge):

def foo(a):
    # now this function is 10 times faster, but only work with positive integers
    assert a > 0
    # do
    # something with
    # with a

...

foo(4)

...

foo(-1) # now we have a use case where we need to call foo with -1

合并的优点在于，它可以在以后的某个时刻了解发生了什么问题，因此您可以相应地解决问题.重新定位可能会丢弃您需要了解的信息，以了解由自动合并引起的错误.

The advantage of a merge is that a it allows to understand what went wrong at some later point, so you can fix things accordingly. A rebase might throw away information you need to understand bugs caused by automatic merges.

这篇关于使用rebaseif工作流程是否可以使版本控制中的bisect受益?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！