Errors when updating an old git.git repository

Errors when updating an old git.git repository

[Hannu Koivisto]

Greetings,

I just did "git-clone git://git.kernel.org/pub/scm/git/git.git".
git-pull in the resulting repository gives "Already up-to-date."
and "git-pull --tags" does the same.  Just what I'd expect.

Before I did that, I had an old (several months) git.git repository
laying on the hard drive and I updated it with "git pull".  It
complained something tag related and I tried again with "git pull
--tags".  Now I'm in a situation where "git-pull --tags" gives "No
changes." but plain "git-pull" gives me this:

-------------------------------------------------------------------
remote: Generating pack...
remote: Done counting 293 objects.
remote: Result has 214 objects.
remote: Deltifying 214 objects.
remote: 14/214) done14) done
Unpacking 214 objects
remote: Total 214, written 214 (delta 156), reused 181 (delta 123)
 100% (214/214) done
error: no such remote ref refs/heads/jc/bind
error: no such remote ref refs/heads/jc/bind-2
error: no such remote ref refs/heads/gb/diffdelta
* refs/heads/pu: not updating to non-fast forward branch 'pu' of git://git.kernel.org/pub/scm/git/git
  old...new: 0c9951a...f959571
Already up-to-date.
-------------------------------------------------------------------

If I run either git-pull or "git-pull --tags" again, I get the same
results.

Since updating a freshly cloned repository doesn't result to such
an odd behaviour, I assume this old repository is broken somehow.
If someone wants to inspect it, I can make it available via web.

I'm using git 1.4.4.3 on Debian GNU/Linux.

-- 
Hannu

Re: Errors when updating an old git.git repository

[Lars Hjemli]

On 12/26/06, Hannu Koivisto <azure@iki.fi> wrote:
> error: no such remote ref refs/heads/jc/bind
> error: no such remote ref refs/heads/jc/bind-2
> error: no such remote ref refs/heads/gb/diffdelta

I guess you have some branch references in the file
.git/remotes/origin that shouldn't be there, so you can just remove
the lines that mention  'jc/bind', 'jc/bind-2' and 'gb/diffdelta' from
that file.

> * refs/heads/pu: not updating to non-fast forward branch 'pu' of git://git.kernel.org/pub/scm/git/git
>   old...new: 0c9951a...f959571

The pu branch is rebased all the time so it needs a '+' in
.git/remotes/origin to be automatically updated, like this:

Pull: +pu:pu

(or you can run 'git pull -f' to force the update)

-- 
larsh

Re: Errors when updating an old git.git repository

[Hannu Koivisto]

"Lars Hjemli" <hjemli@gmail.com> writes:

> On 12/26/06, Hannu Koivisto <azure@iki.fi> wrote:

> I guess you have some branch references in the file
> .git/remotes/origin that shouldn't be there, so you can just remove
> the lines that mention  'jc/bind', 'jc/bind-2' and 'gb/diffdelta' from
> that file.

Thanks, but I don't need to fix the repository since a clean clone
works, I just wanted to report it so that git can be fixed, if
possible.

>> * refs/heads/pu: not updating to non-fast forward branch 'pu' of git://git.kernel.org/pub/scm/git/git
>>   old...new: 0c9951a...f959571
>
> The pu branch is rebased all the time so it needs a '+' in
> .git/remotes/origin to be automatically updated, like this:
>
> Pull: +pu:pu
>
> (or you can run 'git pull -f' to force the update)

I ran 'git pull -f' and it gave me this:

-------------------------------------------------------------------
remote: Generating pack...
remote: Done counting 293 objects.
remote: Result has 214 objects.
remote: Deltifying 214 objects.
remote:  100% (214/214) done
Unpacking 214 objects
remote: Total 214, written 214 (delta 156), reused 181 (delta 123)
 100% (214/214) done
error: no such remote ref refs/heads/jc/bind
error: no such remote ref refs/heads/jc/bind-2
error: no such remote ref refs/heads/gb/diffdelta
* refs/heads/pu: forcing update to non-fast forward branch 'pu' of git://git.kernel.org/pub/scm/git/git
  old...new: 0c9951a...f959571
* refs/heads/man: fast forward to branch 'man' of git://git.kernel.org/pub/scm/git/git
  old..new: 55beec2..da0e8b5
* refs/heads/todo: fast forward to branch 'todo' of git://git.kernel.org/pub/scm/git/git
  old..new: a94df75..32e72b6
* refs/heads/next: fast forward to branch 'next' of git://git.kernel.org/pub/scm/git/git
  old..new: 50dae10..9c0d79d
* refs/heads/html: fast forward to branch 'html' of git://git.kernel.org/pub/scm/git/git
  old..new: 30e1db1..d793de5
Fetch failure: git://git.kernel.org/pub/scm/git/git.git
Already up-to-date.
-------------------------------------------------------------------

Now further 'git pull's also display "Fetch failure:
git://git.kernel.org/pub/scm/git/git.git".  It no longer mentions
the 'pu' branch, though.

-- 
Hannu

Re: Errors when updating an old git.git repository

[Johannes Schindelin]

Hi,

On Tue, 26 Dec 2006, Hannu Koivisto wrote:

> "Lars Hjemli" <hjemli@gmail.com> writes:
> 
> > On 12/26/06, Hannu Koivisto <azure@iki.fi> wrote:
> 
> > I guess you have some branch references in the file
> > .git/remotes/origin that shouldn't be there, so you can just remove
> > the lines that mention  'jc/bind', 'jc/bind-2' and 'gb/diffdelta' from
> > that file.
> 
> Thanks, but I don't need to fix the repository since a clean clone 
> works, I just wanted to report it so that git can be fixed, if possible.

Git works quite as expected here, so there is nothing to fix.

> error: no such remote ref refs/heads/jc/bind
> error: no such remote ref refs/heads/jc/bind-2
> error: no such remote ref refs/heads/gb/diffdelta

Since you said it is an older git repository, I guess that in your 
.git/remotes/origin are some lines like this:

	Pull: refs/heads/jc/bind:refs/heads/jc/bind

So, you _asked_ git to fetch these three branches! By not providing _any_ 
remote, you said: "look into .git/remotes/origin". And in that file you 
said: "fetch bind, bind-2 and diffdelta".

And git faithfully reports that it cannot fetch these branches (they are 
no longer there) and errors out.

Ciao,
Dscho

Re: Errors when updating an old git.git repository

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Git works quite as expected here, so there is nothing to fix.
>
>> error: no such remote ref refs/heads/jc/bind
>> error: no such remote ref refs/heads/jc/bind-2
>> error: no such remote ref refs/heads/gb/diffdelta
>
> Since you said it is an older git repository, I guess that in your 
> .git/remotes/origin are some lines like this:
>
> 	Pull: refs/heads/jc/bind:refs/heads/jc/bind
>
> So, you _asked_ git to fetch these three branches!

I think it only half explains the problem.  Maybe my memory is
failing, but I do not recall pushing out any of these topic
branches, perhaps except jc/bind long time ago.

How did Hannu end up with these branches, both under his
$GIT_DIR/refs/heads/ and in $GIT_DIR/remotes/origin or
remote.origin.fetch in $GIT_DIR/config?

I see identical failure report from ancient time

	http://article.gmane.org/gmane.comp.version-control.git/21629

Maybe I did push them out earlier.

How about doing something like this?  In explain_fetch_failure
I think we could look at $ls_remote_result and automagically fix
remotes/$remote_nick or remote.$remote_nick.fetch, but I am lazy
;-)

-- >8 --

diff --git a/git-fetch.sh b/git-fetch.sh
index ffbd44f..361dfa3 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -81,6 +81,7 @@ case "$#" in
 esac
 
 remote_nick="$1"
+datasrc=$(get_data_source "$1")
 remote=$(get_remote_url "$@")
 refs=
 rref=
@@ -272,6 +273,21 @@ then
 	fi
 fi
 
+explain_fetch_failure () {
+	where=
+	case "$datasrc" in
+	'') ;;
+	config) where="remotes.$remote_nick.fetch configuration" ;;
+	branch) where=".git/branches/$remote_nick file" ;;
+	remotes) where=".git/remotes/$remote_nick file" ;;
+	esac
+	if test "z$where" != z
+	then		  	
+		echo >&2 "You may have stale remote branches in $where"
+		echo >&2 "Remove them if they do not exist anymore."
+	fi
+}
+
 fetch_main () {
   reflist="$1"
   refs=
@@ -325,8 +341,10 @@ fetch_main () {
 			break
 		done
 	  )
-	  expr "z$head" : "z$_x40\$" >/dev/null ||
+	  expr "z$head" : "z$_x40\$" >/dev/null || {
+	  	explain_fetch_failure
 		die "No such ref $remote_name at $remote"
+	  }
 	  echo >&2 "Fetching $remote_name from $remote using $proto"
 	  git-http-fetch -v -a "$head" "$remote/" || exit
 	  ;;
@@ -385,6 +403,7 @@ fetch_main () {
 	  case "$sha1" in
 	  failed)
 		  echo >&2 "Fetch failure: $remote"
+		  explain_fetch_failure
 		  exit 1 ;;
 	  # special line coming from index-pack with the pack name
 	  pack)

Re: Errors when updating an old git.git repository

[Hannu Koivisto]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> On Tue, 26 Dec 2006, Hannu Koivisto wrote:
>
> Git works quite as expected here, so there is nothing to fix.

Since the documentation didn't seem to specify what happens when a
remote branch is deleted (I'm assuming that's the case), _I_ didn't
expect it.

>> error: no such remote ref refs/heads/jc/bind
>> error: no such remote ref refs/heads/jc/bind-2
>> error: no such remote ref refs/heads/gb/diffdelta
>
> Since you said it is an older git repository, I guess that in your 
> .git/remotes/origin are some lines like this:
>
> 	Pull: refs/heads/jc/bind:refs/heads/jc/bind
>
> So, you _asked_ git to fetch these three branches!

Well, that's true from a technical standpoint, but I didn't add
those lines to .git/remotes/origin, git did when I cloned the
repository.  When one updates tracking branches and a branch has
been deleted in the remote repository, I think it wouldn't be
insane to expect git also to remove the line (if not the actual
branch).  If that is not desired, I'd rather the message wasn't an
error but something along the lines of "note: remote branch jc/bind
no longer exists, please update .git/remotes/origin".  It's bit odd
to get errors in a situation that (given the assumption) isn't
erroneous.

-- 
Hannu

Re: Errors when updating an old git.git repository

[Junio C Hamano]

Hannu Koivisto <azure@iki.fi> writes:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> ...
>> So, you _asked_ git to fetch these three branches!
>
> Well, that's true from a technical standpoint, but I didn't add
> those lines to .git/remotes/origin, git did when I cloned the
> repository.  When one updates tracking branches and a branch has
> been deleted in the remote repository, I think it wouldn't be
> insane to expect git also to remove the line (if not the actual
> branch).  If that is not desired, I'd rather the message wasn't an
> error but something along the lines of "note: remote branch jc/bind
> no longer exists, please update .git/remotes/origin".  It's bit odd
> to get errors in a situation that (given the assumption) isn't
> erroneous.

I would be a bit reluctant to remove tracking automagically, but
I fully agree that a comment like that would be needed.

Patches?