Kevin Bracey venit, vidit, dixit 13.05.2013 16:26:
> On 13/05/2013 01:22, Junio C Hamano wrote:
>> Kevin Bracey writes:
>>
>>> git log --ancestry-path --left-right E...F --not $(git merge-base
>>> --all E F)
>>>
>>> which looks like we're having to repeat ourselves because it's not
>>> paying
On 13/05/2013 01:22, Junio C Hamano wrote:
Kevin Bracey writes:
git log --ancestry-path --left-right E...F --not $(git merge-base
--all E F)
which looks like we're having to repeat ourselves because it's not
paying attention...
You are half wrong; "--left-right" is about "do we show the
On Sun, May 12, 2013 at 10:02:39PM -0700, Junio C Hamano wrote:
> Kevin Bracey writes:
>
> > On 12/05/2013 19:58, John Keeping wrote:
> >>
> >> With the patch below, the --ancestry-path version drops to under 2
> >> seconds.
> >>
> >> I'm not sure if this is a good idea though. It helps me say "
Kevin Bracey writes:
> On 12/05/2013 19:58, John Keeping wrote:
>>
>> With the patch below, the --ancestry-path version drops to under 2
>> seconds.
>>
>> I'm not sure if this is a good idea though. It helps me say "I know
>> nothing that isn't on the ancestry path can be patch-identical, so don
Kevin Bracey writes:
> Although I realised after
> sending my mail you could also use
>
>git log --ancestry-path --left-right E...F --not $(git merge-base
> --all E F)
>
> which looks like we're having to repeat ourselves because it's not
> paying attention...
You are half wrong; "--left-rig
On 12/05/2013 19:58, John Keeping wrote:
With the patch below, the --ancestry-path version drops to under 2
seconds.
I'm not sure if this is a good idea though. It helps me say "I know
nothing that isn't on the ancestry path can be patch-identical, so don't
bother checking if it is" but it reg
On 12/05/2013 19:33, John Keeping wrote:
On Sun, May 12, 2013 at 05:28:24PM +0100, John Keeping wrote:
You're right (and I was wrong in my reply to Junio's parallel message)
ancestry path does seem to be what I want:
$ git rev-list --ancestry-path --left-right --count \
master
On Sun, May 12, 2013 at 05:28:24PM +0100, John Keeping wrote:
> However, this doesn't seem to make a difference to the time taken when I
> add in --cherry-mark (which is why I was partially correct in the
> parallel thread - it doesn't have the effect on cherry-mark that I want
> it to):
>
> $
On Sun, May 12, 2013 at 05:28:24PM +0100, John Keeping wrote:
> On Sun, May 12, 2013 at 06:44:30PM +0300, Kevin Bracey wrote:
> > On 11/05/2013 15:23, John Keeping wrote:
> > > This is helpful when examining branches with disjoint roots, for example
> > > because one is periodically merged into a s
On Sun, May 12, 2013 at 06:44:30PM +0300, Kevin Bracey wrote:
> On 11/05/2013 15:23, John Keeping wrote:
> > This is helpful when examining branches with disjoint roots, for example
> > because one is periodically merged into a subtree of the other.
> >
> >
> >
> > $ git log --left-right F
On 11/05/2013 15:23, John Keeping wrote:
This is helpful when examining branches with disjoint roots, for example
because one is periodically merged into a subtree of the other.
$ git log --left-right F...E --not $(git merge-base --merge-child F E)
< F
> E
Wouldn'
On Sat, May 11, 2013 at 10:54:12AM -0700, Junio C Hamano wrote:
> John Keeping writes:
>
> > This is helpful when examining branches with disjoint roots, for example
> > because one is periodically merged into a subtree of the other.
> >
> > With the --merge-child option, "git merge-base" will pr
John Keeping writes:
> This is helpful when examining branches with disjoint roots, for example
> because one is periodically merged into a subtree of the other.
>
> With the --merge-child option, "git merge-base" will print a
> first-parent ancestor of the first revision given, where the commit
13 matches
Mail list logo
