Re: [PATCH] merge-recursive: introduce merge_options

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

 



Miklos Vajna <vmiklos@xxxxxxxxxxxxxx> writes:

> On Sun, Aug 24, 2008 at 11:06:06PM -0700, Junio C Hamano <gitster@xxxxxxxxx> wrote:
>> Miklos Vajna <vmiklos@xxxxxxxxxxxxxx> writes:
>>
>> > 1) This applies on top of 1c868d4 (merge-recursive.c: Add more
>> > generic merge_recursive_generic()). I can rebase this (along with
>> > 1c868d4 and 1c868d4^) on top of current master, if this is a problem.
>>
>> It probably is cleaner to treat this as a fresh topic from scratch on
>> top of 'master', as we do not have anything outstanding in 'next'
>> around this area.
>
> I'm now confused about what should I do:
>
> 1) Nothing. (That's what I did for now.)
>
> 2) Rebase against master and resend.
>
> 3) Rebase, squash and resend.

What I meant was that the final state after applying this patch may make
what "git log master..1c868d4" currently shows (there are two patches if I
recall correctly) an incomplete failed experiment, in which case squashing
and possibly refactoring (if the result of squashing is too messy) would
make the history easier to review.

But I looked at the series again after rebasing them myself.

If you want to clean-it-up, you could replace them by sending in updates
to refactor them.  I think they are still ugly, even though the end result
is tolerable ;-)

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[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