Re: [PATCH v3 00/16] Use merge_recursive() directly in the builtin am

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

 



Hi Junio,

On Mon, 18 Jul 2016, Junio C Hamano wrote:

> Junio C Hamano <gitster@xxxxxxxxx> writes:
> 
> > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> >
> >> The two topics that are in 'pu' and conflict with this series are
> >> 'jh/clean-smudge-annex' and 'bc/cocci'.
> >>
> >> It also conflicted with 'va/i18n-even-more', but that one was merged to
> >> 'master'.
> >>
> >> Now, I think it would be okay to wait for 'bc/cocci' to go to 'master'
> >> before integrating the 'am-3-merge-recursive-direct' branch, but I would
> >> want to avoid waiting for 'jh/clean-smudge-annex'.
> 
> Nothing seems to be happening on jh/clean-smudge-annex front, so
> unless we hear otherwise from Joey in the coming couple of days,
> let's get js/am-3-merge-recursive-direct untangled from its
> dependencies and get it into a shape to hit 'next'.

Okay, I will rebase and re-submit.

> You can assume that I'll merge bc/cocci and
> js/am-call-theirs-theirs-in-fallback-3way to 'master' during that time,
> so an appropriate base to use would be the result of
> 
>     git checkout master^0
>     git merge bc/cocci
>     git merge js/am-call-theirs-theirs-in-fallback-3way
>     git merge cc/apply-am
> 
> if you want a semi-solid base to rebuild am-3-merge-recursive-direct
> on.

Okay. The way my `mail-patch-series.sh` script works, however, is that it
infers the base commit by testing which tip among pu, next and master is
the most appropriate.

So I guess I will have to hack it up a bit to allow basing my patch series
on something custom.

> I am not 100% sure about the doneness of cc/apply-am yet, though but it
> could be that am-3-merge-recursive-direct does not have to depend on it
> at all.  You'd know better than I do ;-)

I agree on the doneness of cc/apply-am (as you know, I tried to help it
along but my comments had an adverse effect).

And no: nothing in my entire rebase--helper patches relies on cc/apply-am
(I do not even believe that anything conflicts with it, either).

> After that, I'll see if the conflict resolution is manageable when
> remerging jh/clean-smudge-annex to 'pu', and if it is not, I'll worry
> about it at that point.

I can help with that, too.

Ciao,
Dscho
--
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]