is through git log, but it's slow and
> > tedious, so I was hoping to be able to implement it into a revision
> > walk that did this.
> >
> > Once I know the commit that introduces the submodule change, I could
> > feed that to git describe --contains to fi
of the specified
> submodule commit.
>
> I can sort of reverse engineer this through git log, but it's slow and
> tedious, so I was hoping to be able to implement it into a revision
> walk that did this.
>
> Once I know the commit that introduces the submodule change, I co
lement it into a revision
walk that did this.
Once I know the commit that introduces the submodule change, I could
feed that to git describe --contains to find the tag/version which
included the change easily enough.
Thanks,
Jake
Hi,
There was an issue with lightweight tags that was supposed to be fixed
in Git 2.14 (by branch jc/name-rev-lw-tag).
I also proposed a patch[1], but that was too late, after the other fix
was already in master.
Anyway, I still have the same issue with git 2.14.2.windows.3.
My repository has b
Thanks Andreas and Nicholas, I'll check it out.
commit, I do not find version 4.8-rc3, nor version 4.8, nor version 4.9, but
> 4.10-rc1:
>
> ~$ git describe --contains bafb2f7d4755bf1571bd5e9a03b97f3fc4fe69ae
> v4.10-rc1~154^2~44^2~178
>
> Why? Why not v4.8-rc3? This means that the patch has been included neither in
> v4.
ns) that
> commit, I do not find version 4.8-rc3, nor version 4.8, nor version 4.9, but
> 4.10-rc1:
>
> ~$ git describe --contains bafb2f7d4755bf1571bd5e9a03b97f3fc4fe69ae
> v4.10-rc1~154^2~44^2~178
>
> Why? Why not v4.8-rc3? This means that the patch has been included neither in
~$ git describe bafb2f7d4755bf1571bd5e9a03b97f3fc4fe69ae
v4.8-rc2-641-gbafb2f7d4755
So I would expect to find it in version 4.8-rc3 and later versions.
However, if I search for the tag that follows (and hence contains) that
commit, I do not find version 4.8-rc3, nor version 4.8, nor version 4.9, but
4.10-rc1:
Jeff King writes:
> On Wed, Mar 04, 2015 at 12:41:57PM -0800, Junio C Hamano wrote:
>
>
>> This one, and $gmane/264101, are a few instances of this known issue
>> raised here recently.
>
> If $gmane/264101 is caused by clock skew, I'd find that disturbing.
> Those algorithms are supposed to be "c
On Wed, Mar 04, 2015 at 12:41:57PM -0800, Junio C Hamano wrote:
> > Calculating them is simple. Caching and storage is the bigger question.
>
> Yes, also having to handle the ones whose generation numbers haven't
> been computed yet adds to the complexity.
I'm not sure it's that bad. If you cach
On Wed, Mar 04, 2015 at 12:41:57PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Wed, Mar 04, 2015 at 04:06:17PM +0100, Michael J Gruber wrote:
> >
> >> Complexity: Was that due to replace refs? Other than that, it seemed to
> >> be simple: max(parent generation numbers)+1.
> >
> > Ca
Jeff King writes:
> On Wed, Mar 04, 2015 at 04:06:17PM +0100, Michael J Gruber wrote:
>
>> Complexity: Was that due to replace refs? Other than that, it seemed to
>> be simple: max(parent generation numbers)+1.
>
> Calculating them is simple. Caching and storage is the bigger question.
Yes, also
On Wed, Mar 04, 2015 at 04:06:17PM +0100, Michael J Gruber wrote:
> > 3. Introduce a more trust-worthy mechanism for ordering commits. The
> > timestamp here is really just a proxy for the oft-discussed
> > "generation number" of the commit within the graph. We've avoided
> > addi
Jeff King venit, vidit, dixit 04.03.2015 11:54:
> On Thu, Feb 26, 2015 at 03:23:14PM +0100, Michal Hocko wrote:
>
>> The commit in the middle was ammended to have committer date in the
>> past.
>> $ git describe --contains d63972e4e4e7eda0444e56739ad09bfbc476b9bd
>
On Thu, Feb 26, 2015 at 03:23:14PM +0100, Michal Hocko wrote:
> The commit in the middle was ammended to have committer date in the
> past.
> $ git describe --contains d63972e4e4e7eda0444e56739ad09bfbc476b9bd
> tag~1
>
> but
> $ git describe --contains 108a0d5972fd2e5f25b
2fee73031ff9d3 Thu Feb 26 14:57:29 2015 +0100
The commit in the middle was ammended to have committer date in the
past.
$ git describe --contains d63972e4e4e7eda0444e56739ad09bfbc476b9bd
tag~1
but
$ git describe --contains 108a0d5972fd2e5f25b2f38cfd2fee73031ff9d3
fatal: cannot describe '108a0d
Hi,
I have just encountered an old kernel git commit:
commit c854363e80b49dd04a4de18ebc379eb8c8806674
Author: Dave Chinner
Date: Sat Feb 6 12:39:36 2010 +1100
xfs: Use delayed write for inodes rather than async V2
[...]
which cannot be described properly:
$ git describe --contains
Hello,
Basically doing: git describe --abbrev=0 gives the closest tag
from
I would expect adding "--contains" option would give the closest tag
containing but it seems that --abbrev=0 has no more effect in
that case:
$ git describe --tags --contains --abbrev=0
7f285fa78d4b81b8458f05e77fb6b462
gt; If I go to look to see what release it was in, I normally do:
> >>$ git describe --contains 0136db586c028f71e7cc21cc183064ff0d5919
> >>v3.6-rc1~59^2~56^2~76
> >> ...
> >> Any ideas?
> >
> > That is 59 + 1 + 56 + 1 + 76 = 193 steps away from the
Junio C Hamano writes:
> Greg KH writes:
>
>> In the Linux kernel tree, commit 0136db586c028f71e7cc21cc183064ff0d5919
>> is a bit "odd".
>>
>> If I go to look to see what release it was in, I normally do:
>> $ git describe --contains 0136db586
Greg KH writes:
> In the Linux kernel tree, commit 0136db586c028f71e7cc21cc183064ff0d5919
> is a bit "odd".
>
> If I go to look to see what release it was in, I normally do:
> $ git describe --contains 0136db586c028f71e7cc21cc183064ff0d5919
> v3.6-rc1~59
Hi,
In the Linux kernel tree, commit 0136db586c028f71e7cc21cc183064ff0d5919
is a bit "odd".
If I go to look to see what release it was in, I normally do:
$ git describe --contains 0136db586c028f71e7cc21cc183064ff0d5919
v3.6-rc1~59^2~56^2~76
However, it really showed u
ned-off-by: Hunt Xu
> > >> Signed-off-by: Daniel Vetter
> > >> ---
> > >> drivers/gpu/drm/i915/i915_sysfs.c | 12
> > >> 1 files changed, 12 insertions(+), 0 deletions(-)
> > >
> > > As commit 0136db586c028f71e7cc21cc183064ff0d5919c
23 matches
Mail list logo
