gocd: Git history rewrite causing errors

(Re-raising here due to no response on the mailing list)

We are facing an error where GoCD cant handle a git repo that has had its history re-written.

(Why would we do that? We are migrating from gitolite to github, and removing files larger than 100meg, which is why we’ve had to re-write history.)

Modification check failed for material: URL: user@url:reponame, Branch: master [Mar-24 12:06:32]
Error performing command: --- Command --- git log --date=iso --pretty=medium 2341bcde2f0edfcfc51b806d1b1b0f5be835479e.. --- Environment --- {} --- INPUT ---- --OUTPUT --- --- ERROR --- ERROR: fatal: Invalid revision range 2341bcde2f0edfcfc51b806d1b1b0f5be835479e..HEAD ---

Go seems to store the latest commit in the database, and the rewrite has changed the history so that that commit no longer exists.

The trick of adding a ‘/’ on the end isn’t working - it just shows an error:

Repository user@url:repo/ not found! : Error performing command: --- Command --- git ls-remote user@url:repo/ --- Environment --- {} --- INPUT ---- --OUTPUT --- --- ERROR --- ERROR: FATAL: 'repo/' ends with a '/' ERROR: fatal: The remote end hung up unexpectedly ---

I’ve searched the flyweight directories, and weirdly, it doesn’t appear to have a local copy of this repo.

Any suggestions on how we can fix? Does deleting the material delete it from the database?

About this issue

Original URL
State: closed
Created 9 years ago
Comments: 40 (18 by maintainers)

Most upvoted comments

@jyotisingh’s idea is to make the server forget about the bad material, by changing the URL to be a new one. However, adding a slash at the end does not work, since github does not consider it a valid repo URL. So, you can try one of the other options:

# Does not work
$ git clone git@github.com:gocd/api.go.cd.git/
Cloning into 'api.go.cd'...
ERROR: Repository not found.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


# Works (adding a slash after the colon)
$ git clone git@github.com:/gocd/api.go.cd.git
Cloning into 'api.go.cd'...
remote: Counting objects: 3381, done.
remote: Total 3381 (delta 1), reused 1 (delta 1), pack-reused 3379
Receiving objects: 100% (3381/3381), 1.33 MiB | 0 bytes/s, done.
Resolving deltas: 100% (1835/1835), done.
Checking connectivity... done.


# Works (removing the .git at the end)
$ git clone git@github.com:gocd/api.go.cd
Cloning into 'api.go.cd'...
remote: Counting objects: 3381, done.
remote: Total 3381 (delta 1), reused 1 (delta 1), pack-reused 3379
Receiving objects: 100% (3381/3381), 1.33 MiB | 0 bytes/s, done.
Resolving deltas: 100% (1835/1835), done.
Checking connectivity... done.


# Works (changing the case of the org in the URL)
$ git clone git@github.com:goCD/api.go.cd
Cloning into 'api.go.cd'...
remote: Counting objects: 3381, done.
remote: Total 3381 (delta 1), reused 1 (delta 1), pack-reused 3379
Receiving objects: 100% (3381/3381), 1.33 MiB | 0 bytes/s, done.
Resolving deltas: 100% (1835/1835), done.
Checking connectivity... done.

Any of those three options above should do the trick.

arvindsv on May 23, 2016

I do not understand why GoCD is keeping track of the commit instead of the branch. A branch is indicated in the pipeline configuration, not a commit. Why does GoCD needs this commit ?

Git is a fantastic tool, as it allows you to use it in many ways to have a workflow which fits you (as tools like SVN is way way more directive). When working on a branch, you can merge it and have a merge commit, or you can rebase it first with your destination branch and then have a merge in fast-forward.

Both ways have theirs advantages and inconvenients, but both are perfectly valid. In my team, before a merge, we choose to rebase with destination branch first, as we can build and test the rebased branch, and then when we merge it in destination branch (master, develop, or whatever), we are perfectly sure you are not breaking anything. If you have any conflict on a merge, you loose this guarantee. When resolving this conflict, there is always a chance you are breaking something. You may have then an unstable master (or develop) branch, and we choose to avoid that risk. So, after rebasing a feature branch, you have to push force it, and rewrote it. That’s an inconvenient, yes, but the price to have a stable master/develop. You may think otherwise, and I’m good with it, as Git allows you to choose a workflow that fits your needs.

In the current state, GoCD forbids us to use a rebase/merge-ff workflow, a valid workflow So, don’t you agree it is a bug then ?

Chcap on Apr 23, 2016

Not respecting the material repo/branch specified as a material is, in my opinion a bug. If the branch is force pushed, NOT reflecting the state of the branch is actually a serious problem, and can cause undue headache if an issue that gets introduced is not surfaced immediately. A manual retrigger of a build should reflect the actual state of the materials in my opinion.

jeremyong on Dec 18, 2015

I do not understand why GoCD is keeping track of the commit instead of the branch. A branch is indicated in the pipeline configuration, not a commit. Why does GoCD needs this commit ?

Because the whole point of GoCD is to know what has changed between the last time it ran a pipeline and this time, and then run it. The commit is also needed for reruns of a pipeline (so that it can reset HEAD back to the commit it had seen before). In fact, the branch is just ancillary. The commit is more important.

But, I think it should be allowed to use rebase/merge-ff workflow. I don’t know whether it should just ignore the previous commit and differences silently or make it optional, though.

arvindsv on Apr 27, 2016

I think we have the same issue here: https://github.com/gocd/gocd/issues/2110

jguilloux71 on Apr 22, 2016