On Wed, Aug 15, 2012 at 11:39 AM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>> Makes sense, I'll try to implement it that way. I was afraid that
>> we would need to call prepare_revision_walk() once first and then
>> if we afterwards find out that we should not walk, we would need
>
Martin von Zweigbergk writes:
> Makes sense, I'll try to implement it that way. I was afraid that
> we would need to call prepare_revision_walk() once first and then
> if we afterwards find out that we should not walk, we would need
> to call it again without the reverse option.
> But after look
On Wed, Aug 15, 2012 at 10:16 AM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>> So all of the above case give the right result in the end as long
>> as the timestamps are chronological, and case 1) gives the right
>> result regardless. The other two cases only works in most cases
>>
Martin von Zweigbergk writes:
> So all of the above case give the right result in the end as long
> as the timestamps are chronological, and case 1) gives the right
> result regardless. The other two cases only works in most cases
> because the unexpcted sorting when no-walk is in effect
> counte
On Mon, Aug 13, 2012 at 2:05 PM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>> To connect to the other mail I sent on this thread (in parallel with
>> yours), do you think "git cherrry-pick HEAD HEAD~1" should apply the
>> commits in the same order as "git cherry-pick HEAD~2..HEAD" (
Martin von Zweigbergk writes:
> To connect to the other mail I sent on this thread (in parallel with
> yours), do you think "git cherrry-pick HEAD HEAD~1" should apply the
> commits in the same order as "git cherry-pick HEAD~2..HEAD" (which
> would give the same result if passed to 'rev-list --no
Martin von Zweigbergk writes:
> By the way, I can see the usefulness of --reverse when giving a range,
> but I think it's a little confusing when not giving a range.
"git rev-list --reverse --root v1.0.0" is a way to say "give me a
list of commits to be replayed in sequence" without having a bot
On Mon, Aug 13, 2012 at 1:05 PM, Junio C Hamano wrote:
> y...@google.com writes:
>
>> From: Martin von Zweigbergk
>>
>> 'git cherry-pick' internally sets the --reverse option while walking
>> revisions, so that 'git cherry-pick branch@{u}..branch' will apply the
>> revisions starting at the oldes
On Sun, Aug 12, 2012 at 11:27 PM, wrote:
> From: Martin von Zweigbergk
>
> 'git cherry-pick' internally sets the --reverse option while walking
> revisions, so that 'git cherry-pick branch@{u}..branch' will apply the
> revisions starting at the oldest one.
By the way, I can see the usefulness o
y...@google.com writes:
> From: Martin von Zweigbergk
>
> 'git cherry-pick' internally sets the --reverse option while walking
> revisions, so that 'git cherry-pick branch@{u}..branch' will apply the
> revisions starting at the oldest one. If no uninteresing revisions are
> given, --no-walk is im
From: Martin von Zweigbergk
'git cherry-pick' internally sets the --reverse option while walking
revisions, so that 'git cherry-pick branch@{u}..branch' will apply the
revisions starting at the oldest one. If no uninteresing revisions are
given, --no-walk is implied. Still, the documentation for
11 matches
Mail list logo
