On Thu, Oct 22, 2015 at 12:11:23PM -0700, Junio C Hamano wrote:
> Max Kirillov writes:
>> On Wed, Oct 21, 2015 at 09:25:37PM -0700, Junio C Hamano wrote:
>>
>>> The logic you implemented feels solid to me, at least at a first
>>> glance. What kind of gotchas are you worried
Max Kirillov writes:
> This additionally forbids having several end commits
> (git blame --reverse --first-parent ^A B C ...), but
> this does not seem to have much practical use.
Even if there were practical uses for a request with multiple end
points, a solution that
(1)
Max Kirillov writes:
> On Wed, Oct 21, 2015 at 09:25:37PM -0700, Junio C Hamano wrote:
>
>> The logic you implemented feels solid to me, at least at a first
>> glance. What kind of gotchas are you worried about?
>
> The fact than arbitrary commit's children are unknown does
>
On Wed, Oct 21, 2015 at 09:25:37PM -0700, Junio C Hamano wrote:
> Max Kirillov writes:
>
>> Do not die immediately when the two flags are specified. Instead
>> check that the specified range is along first-parent chain. Exploit
>> how prepare_revision_walk() handles
Max Kirillov writes:
> Do not die immediately when the two flags are specified. Instead
> check that the specified range is along first-parent chain. Exploit
> how prepare_revision_walk() handles first_parent_only flag: the commits
> outside of first-parent chain are either
Do not die immediately when the two flags are specified. Instead
check that the specified range is along first-parent chain. Exploit
how prepare_revision_walk() handles first_parent_only flag: the commits
outside of first-parent chain are either unknown (and do not have any
children recorded) or
6 matches
Mail list logo