Re: [PATCH] merge: refuse to create too cool a merge by default

Linus Torvalds writes: > ... And I guess it might not be too nasty > to add: it could be done as part of the object checking pass after > downloading the pack. Was that what you were thinking of? Not that fancy, actually. Running an equivalent of git

Re: [PATCH] merge: refuse to create too cool a merge by default

On Wed, Apr 6, 2016 at 11:36 AM, Junio C Hamano wrote: > > I was reviewing the topics to merge to 'master', and a thought > crossed my mind. Both of our series only refuse to create a merge > that does not have any common ancestor, but shouldn't the right > solution refuse to

Re: [PATCH] merge: refuse to create too cool a merge by default

Linus Torvalds writes: > On Fri, Mar 18, 2016 at 1:21 PM, Junio C Hamano wrote: >> While it makes sense to allow merging unrelated histories of two >> projects that started independently into one, in the way "gitk" was >> merged to "git" itself

Re: [PATCH] merge: refuse to create too cool a merge by default

Linus Torvalds writes: > Mine was slightly different, I just went with a "unrelated" merge option. Yeah, I was debating myself if this should be -Xunrelated specific to recursive or an option that is meant for all strategies. I can go either way, but I think a

Re: [PATCH] merge: refuse to create too cool a merge by default

On Fri, Mar 18, 2016 at 1:21 PM, Junio C Hamano wrote: > While it makes sense to allow merging unrelated histories of two > projects that started independently into one, in the way "gitk" was > merged to "git" itself aka "the coolest merge ever", such a merge is > still an

Re: [PATCH] merge: refuse to create too cool a merge by default

On Fri, Mar 18, 2016 at 4:21 PM, Junio C Hamano wrote: > While it makes sense to allow merging unrelated histories of two > projects that started independently into one, in the way "gitk" was > merged to "git" itself aka "the coolest merge ever", such a merge is > still an

Re: [PATCH] merge: refuse to create too cool a merge by default

On 18/03/16 20:21, Junio C Hamano wrote: > While it makes sense to allow merging unrelated histories of two > projects that started independently into one, in the way "gitk" was > merged to "git" itself aka "the coolest merge ever", such a merge is > still an unusual event. Worse, if somebody

Re: [PATCH] merge: refuse to create too cool a merge by default

On Fri, 2016-03-18 at 13:21 -0700, Junio C Hamano wrote: > Many tests that are updated by this patch does the > pass-through manually by turning: Nit: Should be many tests ... do Also, I didn't notice a test that shows that "cool" merges without allow-unrelated-histories are forbidden. -- To

[PATCH] merge: refuse to create too cool a merge by default

While it makes sense to allow merging unrelated histories of two projects that started independently into one, in the way "gitk" was merged to "git" itself aka "the coolest merge ever", such a merge is still an unusual event. Worse, if somebody creates an independent history by starting from a

Re: [PATCH] merge: refuse to create too cool a merge by default

David Turner writes: > Also, I didn't notice a test that shows that "cool" merges without > allow-unrelated-histories are forbidden. Yeah, because I didn't write one in the version that was sent out, which has been corrected in the one that will be on 'pu'. Thanks. --