Skip to content

Creating a new repository overrides remote changes to the gitolite-admin repo #546

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
SomeBdyElse opened this issue Dec 2, 2015 · 4 comments
Assignees
Labels

Comments

@SomeBdyElse
Copy link

redmine_git_hosting seems to be incompatible with remote changes to the gitolite-admin repository.

On my dev machine, I add a new file to the gitolite-admin repository, commit and push it

$ git clone [email protected]:gitolite-admin
Cloning into 'gitolite-admin'...
remote: Counting objects: 128, done.
remote: Compressing objects: 100% (122/122), done.
remote: Total 128 (delta 44), reused 0 (delta 0)
Receiving objects: 100% (128/128), 14.85 KiB | 0 bytes/s, done.
Resolving deltas: 100% (44/44), done.
Checking connectivity... done.

$ cd gitolite-admin/
$ echo "Some nice message to the redmine_git_hosting instance on Redmine" >> testfile
$ ls -la
total 8
drwxr-xr-x  5 XXX  staff  204 Dec  2 09:21 .
drwxr-xr-x  3 XXX  staff  102 Dec  2 09:21 ..
drwxr-xr-x  8 XXX  staff  442 Dec  2 09:21 .git
drwxr-xr-x  2 XXX  staff  170 Dec  2 09:21 conf
drwxr-xr-x  3 XXX  staff  170 Dec  2 09:21 keydir
-rw-r--r--  1 XXX  staff    8 Dec  2 09:21 testfile

# let's commit and push it
$ git add .
$ git commit -m "add testfile"
[master f0fa6b3] add testfile
 1 file changed, 1 insertion(+)
 create mode 100644 testfile

$ git push
Counting objects: 3, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 309 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To [email protected]:gitolite-admin
   2b062f7..f0fa6b3  master -> master

# done

Now, I go to Redmine and add a Gitolite repository to an existing project

Afterwards, I get the feeling that somebody deleted my last commit to the gitolite-admin master. So I will go and check

# I am still in my gitadmin-admin clone
$ git pull
remote: Counting objects: 9, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 5 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (5/5), done.
From XXX.de:gitolite-admin
   f0fa6b3..8b16578  master     -> origin/master
First, rewinding head to replay your work on top of it...
Fast-forwarded master to 8b165784d730c4cb0e52fd8c08efc73e36c257b8.

# Oh yes, there are remote changes. Let's see if my file is still there
$ ls -la
total 0
drwxr-xr-x  5 XXX  staff  170 Dec  2 09:24 .
drwxr-xr-x  3 XXX  staff  102 Dec  2 09:21 ..
drwxr-xr-x  8 XXX  staff  544 Dec  2 09:24 .git
drwxr-xr-x  2 XXX  staff  170 Dec  2 09:24 conf
drwxr-xr-x  3 XXX  staff  170 Dec  2 09:21 keydir

# Oh no, my testfile it is gone! Who took it?
$ git log
commit 8b165784d730c4cb0e52fd8c08efc73e36c257b8
Author: XXX Redmine <[email protected]>
Date:   Wed Dec 2 09:24:07 2015 +0100

    add_repository : XXX-XXX/XXX-XXX-main

commit e7415568036e1b45b8cddc0fc897f2e401336b3c
Merge: 2b062f7 f0fa6b3
Author: XXX Redmine <[email protected]>
Date:   Wed Dec 2 09:24:07 2015 +0100

    [gitolite-rugged] Merged `origin/master` into `master`

commit f0fa6b3fc54aefe0988542a3944aac5ea5a1bfe1
Author: XXX XXX <[email protected]>
Date:   Wed Dec 2 09:22:12 2015 +0100

    add testfile

# …

# There is a merge commit from gitolite-rugged, pretending to merge my changes
$ git show e7415568036e1b45b8cddc0fc897f2e401336b3c
commit e7415568036e1b45b8cddc0fc897f2e401336b3c
Merge: 2b062f7 f0fa6b3
Author: XXX Redmine <[email protected]>
Date:   Wed Dec 2 09:24:07 2015 +0100

    [gitolite-rugged] Merged `origin/master` into `master`

# Let's see what they did
$ git diff e7415568036e1b45b8cddc0fc897f2e401336b3c
diff --git a/conf/XXX.conf b/conf/XXX.conf
index b62d900..a301307 100644
--- a/conf/XXX.conf
+++ b/conf/XXX.conf
@@ -24,6 +24,15 @@ repo    XXX/XXX-XXX
 repo    XXX-test
   RW+                            = XXX

+repo    XXX-XXX/XXX-XXX-main
+  RW+                            = XXX
+  config redminegitolite.projectid = XXX-XXX
+  config redminegitolite.repositoryid = XXX-XXX-main
+  config redminegitolite.repositorykey = XXX
+  config http.uploadpack = false
+  config http.receivepack = false
+  config multimailhook.enabled = false
+
 repo    XXX/XXX-XXX-first
   RW+                            = XXX
   config redminegitolite.projectid = XXX
diff --git a/testfile b/testfile
deleted file mode 100644
index d95f3ad..0000000
--- a/testfile
+++ /dev/null
@@ -1 +0,0 @@
-Some nice message to the redmine_git_hosting instance on Redmine

# Hey, Mr. gitolite-rugged just deleted my file, not very nice :(

I assume, that the update method of GitoliteAdmin from the gitolite-rugged repository should be responsible for merging my changes, but deletes them instead.
https://github.com/jbox-web/gitolite-rugged/blob/devel/lib/gitolite/gitolite_admin/accessors.rb#L93

      # Updates the repo with changes from remote master
      # Warning: This resets the repo before pulling in the changes.
      #
      def update
        # Reset --hard repo before update
        reset! if @settings[:reset_before_update]

        # Fetch changes from origin
        repo.fetch('origin', credentials: credentials)

        # Create the merged index in memory
        merge_index = repo.merge_commits(local_branch, remote_branch)

        # Complete the merge by comitting it
        Rugged::Commit.create(repo,
          parents:    [local_branch, remote_branch],
          tree:       merge_index.write_tree(repo),
          update_ref: update_ref,
          message:    update_message,
          author:     commit_author,
          committer:  commit_author
        )

        reload!
      end

According to some StackOverflow comments, repo.merge_commits(local_branch, remote_branch) does not merge the remote changes into the checked out working tree. Instead one has to checkout the changes after the merge.

http://stackoverflow.com/questions/27971814/rugged-merge-commit-from-origin-does-not-update-working-tree
http://stackoverflow.com/questions/21842783/rugged-fetch-pull-rebase-possible#27290470

@SomeBdyElse
Copy link
Author

In #544 (comment) @gvandenbosch writes:

however when I do something with the repositories in redmine then the public key is automatically replaced with the path to the key again which then breaks the ssh as well.

That could be related, as Mr. gitolite-rugged does not only delete nice message files, but also public keys and other more substantial changes to the gitolite-admin repo.

@jekel
Copy link

jekel commented Dec 3, 2015

have the same problem with latest version

@gvandenbosch
Copy link

So what would be the last working version and would it help to downgrade to there?

@PowerKiKi
Copy link
Collaborator

As discussed in #732 (comment), issues related to Redmine < 4.0 or severely outdated issues are being closed to help clean up the issue tracker.

If this issue is still relevant to you and you are running Redmine >= 4.0, please open a new issue including all new relevant information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants