Re: Unexpected or wrong ff, no-ff and ff-only behaviour

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Junio C Hamano <gitster@xxxxxxxxx> writes:

[...]

> The "the tip being merged into the mainline must always be
> fast-forwardable",

It's rather "the tip being merged into the mainline must be fast-forwardable the
first time it is merged".

> however, is not consistent with the topic branch workflow, and I do
> not mean this in the sense that you should never rebase just before
> submitting (which is a bad practice). For an initial merge of the
> topic to the mainline, the project can keep rebasing to the
> then-current tip of the mainline, and as long as they can afford the
> cycle to test the result, "record the range of the topic branch by
> making a redundant merge" would work.

Yes, that's exactly it, and, as the rule holds for the first topic merge
only, the rest of workflow is as usual, no drastic changes.

Overall, it only ensures the first merge of the topic is semantically
simpler, nothing more.

-- Sergey



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux