[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#784907: marked as done (vcswatch: Fails to parse Git HEAD if multiple branches point at HEAD)

Your message dated Fri, 19 Jan 2018 17:12:13 +0100
with message-id <20180119161213.GA1320@msg.df7cb.de>
and subject line Re: Bug#784907: vcswatch: Fails to parse Git HEAD if multiple branches point at HEAD
has caused the Debian Bug report #784907,
regarding vcswatch: Fails to parse Git HEAD if multiple branches point at HEAD
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
784907: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784907
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: qa.debian.org
Severity: normal

Hi,

as discussed today on #debian-qa, there is an issue with vcswatch working on a
Git repository that has more than branch pointing to the same commit as HEAD:

12:47 < micha> I would like to know why vcswatch has issues with abtransfers
12:47 < micha> https://qa.debian.org/cgi-bin/vcswatch?package=abtransfers

....

15:05 < jamessan> micha: and the error is what it says -- Failure getting HEAD.
		  You have no HEAD ref in your repo.  Looks like you need to
		  run "git symbolic-ref HEAD …" to specify what branch you want
                  to be the default branch when someone clones
15:05 < jamessan> I'm guessing it should be pointing at unstable, so
                  “git symbolic-ref HEAD refs/heads/unstable”
15:06 < jcristau> hmm?
15:06 < jcristau> $ git ls-remote git://source.lenk.info/git/abtransfers.git | grep HEAD
15:06 < jcristau> 2ad5a5e2fdb69742703b1a37de8dda594e153729        HEAD
15:08 < jamessan> oh, the problem is rather that it's ambiguous
15:08 < jamessan> 2ad5a5e2fdb69742703b1a37de8dda594e153729        HEAD
15:08 < jamessan> 2ad5a5e2fdb69742703b1a37de8dda594e153729        refs/heads/master
15:08 < jamessan> 2ad5a5e2fdb69742703b1a37de8dda594e153729        refs/heads/unstable
15:09 < micha> hmm, but is this then my fault?
15:10 < micha> would deleting one of the two branches solve the issue?
15:11 < jamessan> maybe, but vcswatch could probably be improved to just get
		  the sha that HEAD points to and use that instead of trying to
                  parse HEAD out of “git remote show origin”

Cheers,
Micha

--- End Message ---
--- Begin Message --- 
Re: Micha Lenk 2015-05-10 <20150510132522.28863.51726.reportbug@piri.lenk.info>
> as discussed today on #debian-qa, there is an issue with vcswatch working on a
> Git repository that has more than branch pointing to the same commit as HEAD:

I believe that has been fixed - the logic has been revamped several
times, and the current code should be robust against duplicate
entries. (Sadly, it still doesn't just retrieve the HEAD info from the
remote server, because that requires a certain git version there.)

https://salsa.debian.org/qa/qa/blob/master/data/vcswatch/vcswatch#L311-332

Christoph

--- End Message ---
Reply to: