[bitbake-devel] [PATCH] bitbake: bb.fetch2.git: Fix _latest_revision function while using tags

[Olof Johansson]

On 14-01-07 14:40 +0100, Richard Purdie wrote:
> On Tue, 2014-01-07 at 11:36 +0100, Olof Johansson wrote:
> > On 14-01-05 02:53 +0100, Andrei Gherzan wrote:
> > > When getting the revision we must take into consideration if the name we are
> > > looking for is a tag and in that case we need the dereferenced commit ID in
> > > order to check for it existance in a specific branch.
> > > 
> > > So first search for the reference^{} commit ID and only if that returns nothing
> > > get the name as it is.
> > 
> > I think this is the same issue I've tried to solve in a patch i
> > sent in December (subject: bb.fetch2.git: support resolving both
> > tags and branches). I haven't heard anything about it yet though.
> 
> I put this off as I wanted to spend some time and see if we couldn't
> come up with something simpler. Andrei's patch is simpler, the question
> is whether it covers all the cases and whether we even need the fallback
> code?

I agree with your reasoning with regards to not needing a
fallback for Andrei's patch, but my patch tries to first resolve
refs/tags/<tag> (fully qualified) and then falls back to try
refs/heads/<branch>. The reason for this is that ls-remote will
return things like refs/heads/lalala/<tag> if you only do
ls-remote <tag>.

My attempt was also to break out the tasks into simple,
atomic(-ish) functions that would later be easier to write unit
tests for. You complained on IRC that changes to the fetcher
usually comes back to bite you. I believe increased unit test
coverage on low level functions, as a compliment to the existing
more high level suite, can be beneficial in this regard.


Also, if you are holding things off, I would really appreciate
you letting us know so that we can make appropriate workarounds
if needed (as in this case, where we have had to supsend testing
on master :-().

Regards,
-- 
olofjn